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Conference Paper: 


HP 3000 International Users Group Meeting 


7. Oct. 1981 


On the Use of "Prototyping" in Software Development 


C. Floyd 


Institute for Applied Informatics 


Technical University Berlin 


The phrase "rapid prototyping" is currently en vogue in 
certain software engineering circles. The basic idea is to 
aid communication between software producers and software 
users (customers), in particular during the early stages of 
software development, by furnishing experimental versions of 


the system, to be tried out. as part of requirement analysis. 
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In what follows [ will attempt to demonstrate the role that 
a software-"prototype" might assume in different production 
settings in a manner compatible with the main line of 
software engineering's strive for a methodology, as 
illustrated for example in Prof. Turskis lecture at this 
meeting on October 9th (/TURSKI 81/). To begin. with, 
however, some comments about the phrase "rapid prototyping" 
are in order, since this promises to be yet another 
unfortunate misnomer, which may well lead to serious 
misunderstandings, if ever this technique should be adopted 


by the software industry. A prototype is a well established 


‘concept in the engineering disciplines where it refers to 


the first functioning version of a new kind of product. In 
this context, a prototype is intended to exhibit all 
essential features of the final product and thus becomes the 
basis for experiments before the beginning of large scale 
production. This analogy does not carry over’ easily to 


software production, where we are not faced with mass 


production at all. Surely, if we use the concept of a 
prototype in software production - as I will do from now 
onwards, though under protest - we shall have to give it a 


new meaning appropriate for our purposes. 
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The second unfortunate term in the phrase is the epithet 
"rapid", which misleads us into believing that spced is the 
essential aspect in building a prototype. Again, this is in 
conflict with the engineering tradition, where the prototype 
is the final result of careful design, extensive 
calculations and field tests. I fail to see how a software 
prototype produced rapidly, without the careful preparations 
mentioned above will yield reliable answers in determining 


actual requirements. 


In order to judge the usefulness of prototyping in software 


development we must find answers to the following questions: 


Why is communication about software requirements based as 
it is on interviews, checklists and bulky documents not 
sufficiently reliable and how could a prototype be helpful 


in this context? 


- How does the software prototype relate to the final 


product? 


- Is there one, or are there several prototypes and how are 


they evaluated? 


- Under what circumstances can we justify the additional 
investment brought about by producing a prototype in the 


early stages, i.e. what do we hope to gain later on? 


- How does prototyping relate to an orderly approach to 
software development, based on deriving a program from a 
rigorous specification according to the rules. of 


programming methodology? 


As a starting point in answering these questions we should 


take a close look at the well known phase-oriented approach 
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to software development, its merits and shortcomings (see 
for example /LEHMANN 80/). The phase-oriented approach was 
devised as a means to find contractual bases in software 
development and to define intermediate results in terms of 
documents, which form the basis for subsequent work. The 
phase-oriented approach relies on some important 


assumptions, as there are: 


- that requirements, at least in principle, can be fixed in 


advance, 


- that documents, provided that their contents are described 
in a sufficiently rigorous manner, are adequate asa 
primary means of communication, i.e. that the customer 


knows what he will get when he signs the contract. 


Both of these assumptions unfortunately are contradicted in 
the daily practice of software professionals who are faced 
with the difficult task to base their own work on existing 
base-line documents, while at the same time coping with 
constantly changing requirements from their customers. The 
phase-oriented approach does of course permit to go back to 
earlier phases when needed, but it does not encourage the 


planing of profound revisions. 


The phase-oriented approach provides a sound basis to limit 
the liability of the software producer. The’ product is 
defined by its specification and the liability of the 
software producer ends when he has derived a program, which 
is correct with respect to its specification. As Prof. 
Turski will point out in two days, this is a highly 
nontrivial activity which is well supported by modern 
software engineering techniques. Yet, experience shows, that 
even a correct program may not at all be adequate to fit the 
user's needs, because of far reaching misconceptions about 


the actual requirements. 
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The situation is aggravated by the fact that mistakes made 
early in software development are the most costly to 
correct. Serious mistakes in requirement analysis may well 
be too costly to correct at all. The user organization will 


have to adapt to the software - not vice versa. 


There are important reasons why it may prove very hard to 
find out detailed software requirements for the development 


of large programs: 


1) It is extremely difficult for people to visualize how 
seemingly minor decisions about software will later on 


affect their work with the system. 


2) It is often extremely difficult to locate all groups of 
people who will be directly or indirectly affected by the 
system. Different user groups often have conflicting 
views about an information system (which they perceive 
from their own perspective), or they simply ignore each 


others needs. 
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The above mentioned difficulties do not pertain to all 
requirements alike, in fact the following classification of 
requirements helps to point out the areas where troubles 


most likely arise. We can distinguish: 


~ functional requirements describing the desired output to 
be produced for a given input (the relation between input 
and output may be highly nontrivial, but it is normally 
governed by a stringent set of rules; whether or not the 
program obeys the same set of rules can be proved - at 


least in principle). 


- performance requirements stating the resources available 
to achieve these functions (it may be difficult to show 
the precise constraints on resources, whether or not the 
program meets these constraints can be measured - at least 


in principle). 


- handling requirements characterizing the manner in which 
the system is to be embedded into the activities of all 


people affected by it. 


Of these three, the hanéling requirements are the least well 
understood. Handling requirements pertain amongst others to 


the following areas of special concern: 


- The design of man-machine interfaces in the widest sense 
(including conceptual models the user must have, in order 


to understand what the system does); 


- The degree of system integration and as a consequence the 
possibility of interfering with or reshuffling the 
system's functions as needed ("conviviality" of the system 
according to Ivan Ilich /ILICH 79/); 
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- The interplay between formalized (i.e. computer-supported) 
and informalized work-steps permitted by the system (with 
the two extremes: the system enforces a working style akin 
to the assembly line or the system offers a tool-box to be 


used as needed). 


This list does not claim to be complete. The examples are 
indicated in order to demonstrate that handling requirements 
will indeed lead to important decisions about software 
structure, that may we]] determine the adequacy) or 


inadequacy of an otherwise correct program! 
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In the absence of a suitable theory of organizations and of 
sound user psychology, communication with the user, about 
software requirements, will continue to rely largely on 
experience and intuition. In this context, it is felt by 
many that communication is more reliable, if it is based on 
an already existing program which can be evaluated (albeit 
not systematically since there is no underlying theory how 
this might be done). <A prototype therefore, is to be 
furnished in order to reduce the probability of 
misunderstanding requirements. The additional investment 
needed for its production is justified by the hope that this 
investment is significantly smaller than the costs that are 
likely to arise from the need to adapt an inadequate program 


later on. 


It. should be kept in mind, that the production of a 
prototype is justifiable only in the case of long-life 
systems, where a further expansion of the early phases wil] 
presumably lead to profits over a considerable period of 
time. Further, this technique is particularly relevant for 
programs which are embedded in technical or socio-technical 
environments, because such programs will have elaborate 


handling requirements associated with them. 


How then, does a software prototype relate to the actual 
product’ in time, scope and quality? We can distinguish 


several feasible approaches here: 


- the prototype may be intended to aid requirements analysis 
only or it. may be intended to accompany the actual system 


throughout its Lifetime. 


- The prototype may be intended to cover essentially the 
same scope as the actual system or it may be intended to 


exhibit selected features only. 
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The intention of the propagators of "rapid prototyping" 
seems to be to produce throw-away prototypes - with the 
same functional scope as the actual system, but of lower 
quality - which precede the development of the actual 
system itself. This approach implies the call for new 
techniques, such as prototyping languages and 
interpreters, which reduce the effort of prototype 
production. I would like to point out that this approach 


is highly problematic: 


Since the specification does not yet exist at the time of 
prototype production, it is not clear what the functional 
scope of the prototype should be, and we find ourselves 
thrown back into the kind working style which was - with 


good reason - deplored ever since the 1960's. 


Should the specification already exist, it is not clear 
what is to be gained by quickly producing a system with 
the same functional scope, but of lesser quality than the 
final product. It should be remembered that the essential 
thing about the prototype is its evaluation, for which 
there is no systematic basis available as yet and which 
will prove to be a large effort if the prototype itself is 
complex. Therefore the feedback obtained by the evaluation 
of such a prototype will come late and will be unreliable. 
The production of the real system will be delayed, with no 
obvious gain to justify the delay. 


If the prototype is to precede, rather than to accompany, 
the actual system it will not’ be helpful in dealing with 


changing requirements, as will be argued below. 
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Requirements for software embedded in technical or 


socio-technical systems must be expected to change, because 


original requirements were misstated (the probability of 


this may perhaps be reduced with a "rapid prototype"), 
- the environment evolves and develops new requirements, 


- the system, once in use, transforms its environment and 


thus itself contributes to producing new requirements. 


Because of the last two of these points, a "rapid" 
throw-away prototype cannot be expected to aid in reducing 


troubles with changing requirements in the long term. 


In view of all the problems cited above it seems appropriate 
to drop the analogy with engineering prototypes, to 
generalize the concept of a "software prototype" 
considerably and to combine its’ production with an orderly 


approach to software production. 


In the following, a prototype will designate a preliminary 
version of the actual system which exhibits selected 


features of the final product. 


There may be one or a_ series of such prototypes, depending 
on the needs of the specific project. The prototypes serve 
primarily to aid discussions about handling requirements, 
i.e. whereas their functional scope may be only a fraction 
of the actual product's; they are carefully designed, so as 
to illustrate how the system can be embedded into its 


working environment. 


This way of using prototypes implies a different view of 


software development, which has been termed the 
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process-oriented approach elsewhere (/FLOYD 81/). Rather 
than viewing software development as the production of one 
program, by going through several phases and ending up in 
"installation" and "maintenance", I prefer to view software 
development as a sequence of development cycles (re-)design, 
(re-)implementation and (re-)evaluation. It must be 
emphasized, that each development cycle is based ona 
specification from which the program version to be produced 
can be derived in an orderly fashion, thus’ there is no 
contradiction between this approach and software engineering 
methodology; instead the specification itself is viewed as 


an evolving document. 


As opposed to the common phase-oriented approach, 
communication with the user is continuous and feedback from 
the evaluation of successive prototypes is incorporated into 


redesign at the end of each development cycle. 


The specification serves as a common defining document for 
both software producer and user. In particular, the 
application model associated with the specification must be 
phrased so as to exhibit the embedment characteristics of 


the system in its working environment. 


The responsebility of the user consists in providing, in 
each development cycle, an evaluation basis for the 
prototype which can be derived from the application model. 
In the absence of a theory we can still point to no 
systematic way of how to do this, but at least the new 


framework will allow to progress in small, meaningful steps. 


In the context of the modified approach to software 
development described above, a prototype can assume one of 


the following roles: 
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1) A prototype may coexist with the actual product; it is, 
then, a program model of the same specification, less 
rigorously treated, and serves as basis of experimental 


changes before the program itself gets modified. 


2) A prototype may coincide with the actual product: This is 
intended in version-oriented software production in 
development cycles, as described above. The specification 
‘is an evolving document; it may or may not change from 


one version to the next. 


3) The product itself is a prototype: This arrangement is 
relevant to the production of standard software, which is 
designed to meet the functional requirements of a class 
of asens; but where handling requirements can be decided 
by replugging existing components to fit individual 


needs. 


4) Production starts from a prototype: Analysis and redesign 
of existing software can be viewed as a special case of 


the same approach. 


Each of these arrangements may prove a valuable help to aid 
communication with the user in certain production settings 
and each of these can be combined with orderly programming 
methods. How much of a previous’ version of the program can 
be retained to be incorporated into a subsequent version, 
must be decided as part of the redesign effort following 


each development cycle. 


In order not to create false hopes, however, we must 


remember that in this manner we have obtained a more 


flexible framework - no more. Modern software design and 
specification methods do not necessarily facilitate 
incremental partial changes, which makes the use of a 


specification as an evolving document awkward. We all know 
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that in practice the discrepancy between programs’) and 
specifications increase with time, thus making the 
specification obsolete long before the program is shelved. 
We can hope that progress in specification research will 


help to remedy this situation. 


On the other hand, we cannot’ hope that communication with 


the user - even based on carefully designed prototypes - 


will significantly improve, unless we finda theory of 


software embedment which is based on solid grounds in both 
psychology and the social sciences. Such a theory will help 
the software designer to make intelligent choices that can 
be justified to the user by rational arguments, rather than 
by individual tastes. It will also allow for the systematic 


evaluation of prototypes. 


Because of the serious concern for the adequacy of software 
systems in their working environment, research efforts in 
these directions must be considered one important front of 


software engineering research. 
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Security on 


MPE—Systems Introduction Page 1 


What data security means 


o to be able to rebuild the file system 


in case of a disaster 


o to restrict access on various type 


of data 





Security on . 
APE —Systems File Backup Page 2 


Standard File Backup 
Facilities in MPE 


SYSDUMP, RELOAD 
(based on magnetic tape) 


STORE, RESTORE (tapes) 


User Logging 


(based on disc or tape) 


Private volumes (disc) 





Security on 
APE—Systems 


File Backup Page 3 










Problems with 
Standard File Backup 






o tape read error during RELOAD 






— system cannot be started 









— next action "must be RELOAD" 





measures: 


7 
— change disc packs before RELOAD 






— RELOAD with ‘ACCOUNTS—only’ then 
RESTORE the remaining files 
(very time consuming) 









o tape read error during RESTORE 





— all files stored behind error point 
cannot be restored | 







measure: 


— use RESTORE-— or GETFILE2—program 





Security on 


APE —Systems File Backup Page 4 


o user logging causes system overhead 


measure: 


— consider special logging during 


program design 


Prospects for tape—backup system 


o GETFILE-—facility will be 


improved 


o special STORE—RESTORE system is 
considered (this possibly includes 
features like UPDATE and APPEND) 
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MPE-Systems Restrictions Page 5 





Restrictions in Data Access 


account—system (users, groups, 


accounts with different passwords) 
user capabilities (SM, PM, PH, etc.) 
filenames with passwords 
privileged files 


file access capabilities on 


user/group-— and file—level 


RELEASE /SECURE—commands 
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Pecurthy on ahs 
MPE—Systems Restrictions Page 6 


Possible seven Ways 
to crack the system 


1. FIELD.SUPPORT 


measure: 
Password on SUPPORT-account 
or remove SUPPORT-—account 


from the system 
2. Jobs in PUB.SYS-—group 


measure: 
password on job-—file or 


put job into other SYS-—group 
3. LISTUSER @.@;LP 
measure: 


log-on—-UDC or perform command 


not in PUB.SYS—-group 


Security on a 
MPE-—Systems Restrictions Page 7 


4. Open all files of the system 


measure: 
special analysis of system logging 


5. Read terminal buffers (PM—capability 
needed) 


measure: 
remove PM-capability 


6. Reading tapes 
measure: 
keep track of all tape—transactions 
also using system logging 


7. FOPEN on terminals 


measure: ?? 


THE HP 2680 LASER PRINTING SYSTEM 


(OVERVIEW) 


by Jim Langley 
HP 2680A R&D Project Manager 


March 15, 


1981 
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Laser Printer Paper, July 14, 1981 


Abstract 


This paper describes the HP 2680A Laser Printing System from the 
perspective of the HP 3000 programmer. The printer hardware is first 
described, then its features are explained. Concepts of downloadable 
character sets, electronic forms and logical pages are discussed. The 
implementation and use of these printer features via the system 
software is also covered. The impact of the laser printer ina 
distributed computing environment is briefly explored. 


Overview 


The HP 2680A is Hewlett Packards first page printer. It is based on an 
electrophotographic process which was licensed from Canon, a Japanese 
firm. The printer was designed and is manufactured by the Boise 
division in Boise Idaho. 


Several key objectives were established at the start of the program. 
Reliability, flexibility, features matched to 3000 user needs, simple 
powerfail and paper jam recovery, very low CPU overhead, and the 
ability to access the printer and its features from existing programs 
without modification became the primary objectives of the development 
effort. 


From the beginning the printer was designed as an extension of MPE, not 
an added on peripheral. This tight coupling yielded a fully integrated 
printing system that is fully supported by the MPE file system and 
spooler. In addition a powerful subsystem exists which allows complete 
character set and forms design. Flexible page formatting and a full 
complement of intrinsics provide access to all printer features. 


By fully integrating the printer into the 3000 simple and reliable 
power fail and paper jam recovery is realized. All these benefits were 
achieved while the CPU overhead to drive the printer was reduced an 
order of magnitude from that required to drive conventional printers at 
comparable data rates. 


Hardware 


The 2680A is approximately 5.5 feet long, 2.5 feet deep and 4 feet 
high. It weights about 875 pounds. Power requirements are 4500 watts 
when printing. Throughput is 45 8.5 by 11 inch pages per minute. The 
equivalent lines per minute speed is 2900 lpm ranging up to 12000 lpm 
in reduction mode. 


The paper path is short and readily accessible to the operator. It 
features a powered paper stacker. The fusing system is radiant, 
eliminating any pressure or high temperature rollers. Nothing contacts 
the upper side of the paper once the image is transferred from the drum 
to the paper, contributing to excellent reliability. The web is pulled 
by a programmable torque motor on the output tractors, and paper motion 
is gated by stepper motor driven input tractors. A solenoid powered 
retraction mechanism pulls the paper away from the drum when the seam 
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on the drum comes around. The input paper platform acts as a splice 
table; a vacuum is used to hold the paper onto the table when splicing 
a new box of paper onto the end of the previous box. The paper path 
can accomodate various widths up to 12.5 inches and lengths up to 17 
inches. A width sensor on the input tractors allows the printer to 
energize only the correct width in the preheater section of the fuser. 
Paper which is heated produces odors, which are trapped and oxidized in 
replacable filter cartridges. 


The image forming process is electrophotographic. The heart of the 
system is a photoconductive drum about 19 inches in circumference and 
14 inches long. The drum is coated with cadmium sulfide and wrapped in 
mylar for protection. The drum is uniformly erased and then charged to 
several hundred volts at the first station. The laser is then scanned 
across the drum perpendicular to the direction of rotation. The beam 
is modulated to give 180 dots per inch resolution. There are 2048 dots 
in one scan line, giving a printable area 11.38 inches across. The 
drum rotation allows the sweeping laser beam to cover an area 17 inches 
long. The circular dot is about .008 inches in diameter on a grid 
.0055 inches square. When the laser beam hits the drum the voltage is 
depleted. Next the drum rotates past a cloud of fine flour-like black 
plastic. The plastic toner is attracted to areas of no voltage by 
electrostatic forces. The pattern traced by the scanning laser beam is 
now visable as a sharp black image on the drum. Finally the paper and 
the drum are brought together for about 1 inch of tangential contact. 
The paper is correctly charged to firmly attract the toner off the 
drum. The small amount of residual toner not deposited on the paper is 
then scraped off of the drum by a urethane wiper blade and collected by 
a vacuum systen. As the drum turns these processes are executed 
simultaneously at different stations around the drum. 


In order to achieve high print quality over a wide range of ambient 
conditions the HP 2680A has two closed loop control systems. The 
electrostatic control system monitors the potentials on the drum just 
after the laser station. The voltage is measured both where the laser 
exposed the drum and where it did not. The microprocessor taking the 
measurements then controls several programmable power supplys_ to 
maintain the correct drum potentials. The readings and ajustments are 
made once per drum rotation. The electrostatic closed loop compensates 
for variations between replacement drums, drum degradation over time, 
humidity, temperature and altitude variations, and toner mixture 
fatigue. 


A second closed loop system monitors the developed image on the drum to 
control print density on the page. By varying the amount of toner in 
the developer assembly which brushes the toner mixture across the drum 
the amount of toner on the drum and hence the final print darkness on 
the paper can be controlled. 


The mechanical features of the printer were designed to be simple and 
reliable, and the operator functions are easy to learn and execute. A 
vacuum system in the printer contributes to cleanliness. It is used to 
recover toner wiped off the drum. It also is used for the splice table 
and to maintain good contact between the preheater pad in the fuser and 
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the paper. The operator loads a fresh kilogram of toner into the 
machine about once every eight hours of printing. Unused toner is 
collected with the vacuum system, trapped centrifigally and deposited 
in a disposable bottle which is replaced every couple of days. A new 
box of paper is loaded every hour. The new box can be conveniently 
spliced onto the end of the previous box or the new box can be easily 
loaded with the THREAD button. 


There are two microprocessors in the HP 2680A. One is a 16 bit HP 
proprietary SOS device which controls all machine functions such as the 
operator keyboard and alphanumeric display, the paper path, the closed 
loop systems and internal diagnostics. The second processor is a high 
speed bi-polar bit slice processor which communicates with the 3000 and 
performs all processing on the data stream and ultimately modulating 
the laser beam to form the correct images at the proper place on the 
drum. This processor uses 256k bytes of RAM, with a second 256K 
available as an option. Approximately 40K bytes of this memory is used 
for tables and buffers, the remaining memory is partioned dynamically 
during each job for character sets, forms, and page buffering. 


Extensive internal diagnostics constantly monitor the state of the 
machine, alerting the operator if a service engineer should be called. 
When arriving on site the service engineer can use additional 
internally contained diagnostics to troubleshoot any problems. A very 
complete self test program is available which prints many important 
parameters on the machine itself. Data such as serial number, drum 
rotations since last PM, firmware datecodes, and all operating values 
are labeled and printed. The printer contains a limited amount of 
nonvolatile memory. 


Programming Features 


Page printers, even with their inherent benefits of high thruput, low 
noise and exceptional print quality are rarely viable as simple print 
and space devices because of their higher cost. However the HP 2680A 
is a cost effective replacement for many line printers. This is 
because of the flexibility and features of the printer. Electronic 
forms allows the inventory of costly specialty forms to be eliminated. 
Long lead times and form modifiation costs are reduced to a few hours 
on a terminal. Definable character sets allows the printer to be used 
in a wide variety of industries and applications where conventional 
printers are useless. In addition the print quality and crispness in 
conjunction with the 8.5 by 11 inch paper size means HP2680A output 
never needs to be copied or reduced before general distribution. 


The HP2680A implements a concept called logical pages. A physical page 
is a sheet of paper bounded by perforations. A physical page can be 
divided into up to 32 rectangular areas called logical pages. Logical 
pages can overlap. A programmatic command to page eject moves the 
print to the next logical page. If all logical pages have been used, 
the printer goes to the first logical page on the next sheet of paper. 
Each logical page has several attributes such as an associated vertical 
format control (VFC) table, a default line spacing, and one of four 
orientations. In addition each logical page can have up to two forms 
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associated with it. When the logical page is printed the forms are 
automatically’ overlaid by the printer. Several logical pages can share 
the same form and VFC, the printer will automatically relocate it to 
the correct origin for each logical page. Logical pages are a powerful 
concept which particularly supports existing programs. By defining the 
logical page format an existing job can have its output reduced two to 
1 or four to 1 or rotated without even recompiling the job. 
Additionally a job which currently uses preprinted forms can be 
switched to run on the laser printer without modification. The 
existing form is converted to electronic format and then the 
corrsponding logical page is defined to use the form. The job is then 
printed on the laser printer and the data is merged with the form and 
printed. 


The electronic forms capability is designed for maximum flexibility. 
Each form can contain horizontal and vertical lines of varying 
thicknesses, text written with any number of fonts in any of the four 
basic directions, plus areas or boxes of variable shading. Form 
elements can be positioned anywhere and are not restricted to certain 
character positions on the page as a “draw set" is. The printer can 
support 32 different forms simultaneously. Each logical page can use 
up to 2 forms as long as the total does not exceed 30. Additionally 
each physical page can be overlaid with up to 2 forms. Enough memory 
and processing power exists to create a form which is a dot per bit 
image of an 8.5 by 11 inch sheet of paper. Forms are easily created 
for the printer using an interactive program called IDSFORM. 


The HP2680A printer accepts user defined character sets. Each 
character set contains from 1 to 128 characters. Each character has an 
associated cell of a specified size which contains any dot per bit 
representation desired. The spacing between characters and between 
lines can be set to any value. A character set can print in any of the 
four directions. Proportional character sets are supported. In this 
case each character has a parameter describing how far to move over 
after printing each character. The printer also allows the cells to be 
printed in any relationship to the current "pen" position. This allows 
centered symbols, or common base lines so different character sets can 
be mixed properly on a single line. When using more than one character 
set a primary and secondary set are defined and then selected with 
either shift in, shift out control codes or by setting the eigth bit of 
the ASCII code. HP supplies a large number of character sets of 
various fonts and sizes. In addition character sets and logos can be 
created interactively by terminal users via IDSCHAR. 


Thirty two user definable VFC's are supported by the printer 
simultaneously. They are easily created with the IFS2680 program. 


One additional feature was implemented to allow easy emulation of 
multi-part forms. When activated each physical page of data will be 
repeated up to eight times by the printer. As each copy of the page is 
printed, the printer will automatically overlay any two forms on the 
page. In this manner the same data can be repeated up to eight times, 
but each copy can be individually addressed to shipping, purchasing, 
order processing, etc. 
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These basic data structures provide a wide range of user features. 
When combined with the ability to place cells anywhere on the page and 
overlap at will plus the processing power to handle over 20,000 
characters on an 8.5 by 11 inch sheet a truly unique zrinter results. 
The maximum number of cells on any raster scan is 255. As the cells 
get larger, fewer can be printed simultaneously. Character set 
switching, forms overlay and other features all occur at speed. 


The printer's memory is allocated by a memory manager on a job by job 
basis. Approximately 4OK bytes are used by the printer, the remaining 
memory is allocated to character sets, forms, VFC's and page buffering. 
As much memory as required is allocated to the user's character sets, 
forms and VFC's. All remaining memory is used to buffer pages in an 
intermediate linked list structure. More page buffering insures that 
pages are printed at speed. Insufficient page buffering causes a lower 
thruput rate. The programmer can add or delete character sets, forms 
and VFC's during the job. 


Environment Files 


All character sets, forms, VFC's and the logical page table and the 
multicopy forms table are placed in an environment file by a terminal 
user running IFS2680. This file is then sent to the printer at the 
start of a job automatically. This allows the output of a job to 
change appearance by changing the environment file or portions of the 
environment file. For example if the character set in an environment 
file is changed from elite to pica the next job to use the file will 
have output printed in pica. By simply changing the logical page 
description and substituting a smaller character set a job can be made 
to print in a2 to1l1or 4h to 1 reduction mode. HP supplies several 


‘standard environment files to cover portrait mode pica and elite, 


landscape 132 column printer emulation, two to one and four to one 
reduction. The user can easily create additional environment files. 


For new application programs the full power of the printer is available 
through HP supplied intrinsics. The intrinsics allow features such as 
writing a string to a named field on an electronic form. The form can 
be redesigned and rearranged without modification of any programs using 
the form. The data will automatically be placed in the correct field 
wherever it is on the page. Intrinsics also allow the pen to be moved, 
new primary and secondary character sets to be selected, any logical 
page to be turned on or off and other similar features. 


System Software 


Extensive system application software allows creation of character 
sets, forms, VFC's as well as the definition of logical pages and 
multicopy forms tables. 


IDSCHAR provides menu driven interactive creation of character sets on 
graphic terminals. The program can emulate various shaped dots and 
grid spacings. The laser printer has round dots about 8 mils in 
diameter on a 5.5 mil grid. IDSCHAR also supports a digitizer to allow 
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easy input of character or logo outlines. The outline can then be 
scaled and presented superimposed on the cells grid for easy filling 
in. IDSCHAR supports lines, arcs, rectangular area fills plus scaling 
and rotation. Special logo files are supported for use on forms. An 
experienced graphics designer can create a complex logo in 1 to 4 
hours. Generating a high quality character set takes about 40 hours. 


IDSFORM provides menu driven interactive forms creation of forms on 
graphics terminals. It supports horizontal and vertial lines of 3 
different thicknesses. Boxes can be shaded from clear to black. 
IDSFORM supports subforms which can be defined and then easily |lmoved 
around both on the page and between different forms. Windows describe 
boxes consisting of headers and data fields. Data fields can be 
labelled to allow symbolic access allowing the form to be changed 
around without modifying the program. The 1040 tax form was perfectly 
emulated in 14 hours by an experienced user of IDSFORM. 


IFS2680 is the formatting program which bundles up different character 
sets, forms, VFC's and a logical page table into an environment file. 
IFS2680 also is the program which constructs VFC's and the logical page 


table for the user. Overall job parameters such as the number of 
copies of each page desired and the multicopy forms table are specified 
via IFS2680. HP supplied standard environments are available from 


IFS2680 either as they stand or as a base to begin creating a unique 
environment for a special job. 


A contributed program called TR2680 which interprets commands imbedded 
in ASCII files is available. Text editors can be used to prepare memos 
and reports with the imbedded commands to utilize HP2680A features such 
as multiple character sets, forms overlay, pen moves etc. 


Once an environment file is created it is specified with a new option 
in the file equation :FILE PRINT ; DEV=PP;ENV=FOURTO1. The environment 
file is automatically placed in the spool file before the data. This 
allows existing programs to use all of the features accessible via 
environment files without modification. 


Power fail and jam recovery are very simple and reliable. Non volatile 
memory exists in the printer. When power resumes the 3000 retransmits 
the job from the beginning at high speed. The printer processes the 
data and resumes printing at the correct point in the job. The only 
operator invention required is to insure top of form is correctly 
aligned and push run. Paper jams are similar. If no paper was damaged 
the job can be resumed without system intervention. If the operator 
wishes to backup several pages the spooler is suspended, the jam 
cleared, and the command :RESUMESPOOL LDEV#; BACK 5 PAGES is used. 
This allows backing up or skipping forward an arbitrary number of 


pages. 


Another unique concept introduced with the laser printer is the error 
trailer. When a program executes an illegal function such as selecting 
a missing character set, moving the pen off of the logical page or 
trying to print a character off of the logical page the printer relays 
this information to the 3000. This information is then printed out at 
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the end of the job before the trailer is printed. The error trailer 
describes the error in english, along with the record number and actual 
page number where the error occured. 


Distributed Printing 


MRJE has been modified to support HP2680 environment files. If the 
device class is PP for page printer and the forms field is not empty 
then the forms identifier is used to locate an environment file. 


RJE has an option which allows the translator procedure to process each 
record when received by the 3000. This allows complete access to the 
printers features from a mainframe. 


One internal test site is running a Series 30 to front end the laser 
printer. They are printing over 130,000 pages per month. One half of 
the output is generated by an Amdahl 470 and sent at 9600 baud via 
MRJE. 


At 2900 1pm the printer taxes the performance of most data 
communication systems. System configuration, CPU overhead and data 
format determine the printer utilization. The range can be from 10% to 
100%. We are currently quantifying printer performance in these areas 
and welcome user inputs and insights. 


Summary 


The HP2680A laser printing system provides a cost effective solution to 
many computer output problems for HP3000 users. The reliability and 
servicability contribute to its low cost of less than 4 cents per page 
at 200K pages per month. The unmatched features provide capabilities 
unique in the industry. The complete software appliation package 
allows immediate turnkey solutions with no programming. The impact of 
the laser printer in the distributed network is significant and allows 
non HP systems to utilize the printer as well as enhancing distributed 
HP systems. 
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1. Introduction 


RATFOR is a language introduced by Kernighan and Plauger [1] based on 
FORTRAN-66. In their book "Software Tools" they present a preprocessor 
that translates RATFOR into standard FORTRAN-IV. 


In this paper I will first show why RATFOR is a very useful addition 
to other common languages and what we are using it for in Nuclear 
Physics Research and System Programming. 


In chapter 3 the RATFOR syntax will be shortly described and some 
examples will be given. 


In the forth chapter I will present our implementation of a RATFOR 
preprocessor and how to use it on an HP3000 system. 


Conclusions about our experience with RATFOR will be drawn in chapter 


5. 


2. Why use RATFOR as an additional language 


The primary reason for the authors of RATFOR was to make FORTRAN a 
better programming language. With RATFOR it is possible to write much 
more readable and better structured programs. This is achieved by pro- 
viding additional control structures that are not available in 
FORTRAN-66, and by improving the "cosmetics" of the language. 


The added control structures for better structuring of programs are 
IF-ELSE, WHILE-DO, REPEAT-UNTLL, FUR loops, DO loops, and others. An 
INCLUDE statement allows the inclusion of Predefined code or defini- 
tion sequences at certain points. The cosmetics is improved by allow- 
ing the programs to be in free-form. The end of the line marks usually 


D4 2 


the end of the statement, but statements can easily be continued on 
the next line by ending with a comma or with a special continuation 
character. A sharp # anywhere in the line marks the beginning of a 
Comment, thus allowing trailing comments on each line. This certainly 
encourages programmers to add more documentation to the source code. 


Because almost all constructs of standard FORTRAN are retained in 
RATFOR, it is very easy for a FORTRAN programmer to learn RATFOR. 
There is only a very low psychological barrier to switch from FORTRAN 
to RATFOR. 


In addition, you are not lost if you have to transfer one of your 
RATFOR programs to an other installation that has no RATFOR compiler 
available. You simply move the intermediate FORTRAN code to the other 
system. This is of course the way, how the RATFOR preprocessor itself 
is “boot-strapped" on a new machine. 


In addition to the already mentioned features, RATFOR comes with a 
built-in macro processor, which allows not only such constructs like 
EQUATES and DEFINES as in SPL, but also enables you to add additional 


- 


language constructs (in the form of macros) to RATFOR as you need it. 


From all this you see that RATFOR is a better choice than FORTRAN in 
at least all those cases, where you have somewhat more complicated 
control paths ina program. There are only few instances where GOTO 
constructs are needed, and avoiding those makes programs usually more 
readable and better self—documenting. 


Besides applications in Nuclear Physics, we are using RATFOR to imple- 
ment data acquisition and measurement control subsystems as well as 
computer communications systems. RATFOR helps us to write these 
systems to a large extent inamachine independent way, burrying 
machine dependencies in macro definitions. We are currently using 
three type of minicomputers in our institute: HP3000, HP1000, and 
PE3220. 
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3. RATFOR syntax 


3.1 General rules 


There are several characters recognized as special ones in RATFOR: 


$( or { for LEFT BRACE 
$) or } for RIGHT BRACE 


Left and right braces act as delimiters for groups of statements like 
BEGIN and END in SPL. Other special characters are: 


A or ~ for NOT 

\ or | for OR 

& for AND 

[* for MACRO LEFT BRACKET 

*] for MACRO RIGHT BRACKET 

# for the begin of comments 

% 1s the line continuation character 


Any line ending in a comma will also be continued. Include files may 
be nested 3 levels deep. A statement which starts and ends with a 
quote will be stripped of the quotes and placed in column one in the 
output. This is useful for ‘'hiding' Ratfor keywords and for putting 
FORTRAN compiler commands (SCONTROL ...) in column 1. 


Examples; 


*SCONTROL USLINIT,NOSOURCE' 
or 


IF( arith expr) labell, label2,label3' 


(Note: Arithmetic IF statements are not allowed in RATFOR). 


Input is free-field with only few exceptions. Capitals and small 
letters can be used. Embedded comments in a source line start with "#" 
or ee ! we 7 


Blocks are one single statement or several surrounded by braces. This 
is similar to the REGIN/END structure in ALGOL or SPL. The left brace 
"{" corresponds to BEGIN, the right brace "}" to END. 
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3.2 The DO statement 


It resembles the well known FORTRAN DO-statement without the need to 
use a label at the final statement. 


DO I=1,MAX, IDELTA 
A(I)=I 
or 
DO I=1,MAX 


{ 

A( I )=SIN(X(I)) 
B( I )=A(I)**2 

) 


3.3 The FOR statement | 


FOR (I=1 ; I<=100 ; I«I+1) 
<BLOCK> 


<BLOCK> stands for one statemerit or { several statements }. The 
three parts between the parentheses have the following meanings: 


1: (I=1) Initialization statement. This may be ommitted, thus 
starting with a previously defined value. 


2: (I<=100) As long as this condition holds true, the following block 
will be executed. This is tested at the beginning of 


the block. 


3; (I=sI+1) Modification, that is performed at the end of the block. 


All three clauses may be almost arbitrarily complicated, as the 


following example shows: 


FOR (X=0 ; EXP(X)<=1.E70 ; X@ARCSIN(X)+10./Y) 
{ 
PRINT X 
} 
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3.4 The WHILE statement 


WHILE ( X(I) A= 5 ) 
{ 
DISPLAY X(I) 
X( I )=FUNCT( X(I)) 
} 


This allows a block of statements to be repeated while a certain con- 
dition holds true, which is tested at the beginning of each step. 


3.5 The REPEAT statement 


This is the counterpart to the WHILE statement. A block of statements 
is continued until a certain condition, which is tested at the end of 
the block, becomes true: 


REPEAT 
<BLOCK> 
UNTIL (X==Y) 


One may omit the UNTIL-clause to get a REPEAT FOREVER construct. 


3.6 Exits 


The two statements NEXT and BREAK allow to change the sequence of exe- 
cution in DO, FOR, WHILE and REPEAT blocks without the need for GOTO 
statements (which is considered as bad programming style!) and labels. 


NEXT starts over at the beginning of the currently executing block 
(i.e. Starts again at the first statement of the DO or FOR block after 
the appropriate modification of the running index - or whatever was 
requested - has been done: corresponds to a GOTO to the CONTINUE 
statement of a FORTRAN DO loop) 


BREAK continues behind the current block. The DO, FOR, WHILE, or 
REPEAT statement is terminated. 
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Gefine(p1,3.141593) 
3.7 Relational expressions 


Following this macro definition, every occurance of pi (or PI) in the 
The following is a table of the correspondence between FORTRAN and 


text will lead to the insertion of 3.141593 instead of the two 
RATFOR relational and logical operators: 


letters. 
FORTRAN RATFOR define(maxind, 200) 
,EO. ae 
NE. A= integer iarray(maxind),rarray(maxind, 2 ) 
.GT. > 
.GE. ae do i = 1, maxind 
.LT. < larray(1) = 0 
. LE. C=, 
-AND. & This is useful to define dimensions and maximum index values globally. 
.OR. | 
-NOT. “A 


define(tan,[*sin($1)/cos($1)*}) 


This iS a macro with parameters. tan(x/2) will be replaced by 
Sin(x/2)/cos(x/2). With the macro definition, you can write the pro- 
gram as if "tan" were a function, but there are no function calls at 
run-time. For complicated expressions, however, the object code will 
be quite long when you call the macro often. 


3.8 IF and ELSE clauses 
This is similar as in ALGOL or SPL and many other languages: 


IF (logical expression ) 


spieek? Macros can be globally defined for a complete source file. It is best 


to make the definitions at the beginning of the file, maybe with an 
include statement for a file containing the macros. 


or 
IF (logical expression ) 
<block> 
ELSE 


The following example illustrates how powerful the RATFOR macro pro- 
<block> 


cessor can be, 1f you have understood its operation and syntax in 
detail. For instance, it is possible to write easy to use constructs 


for condition code checking after the call of system intrinsics: 
3.9 The INCLUDE statement 


IFN=FOPEN( ... ) 

The INCLUDE statements allows the inclusion of program parts, which BEGINCC 
are stored on a different file, at the point of the INCLUDE statement. se 
INCLUDES may be nested 3 levels deep. << block >> 

CCG 

<< block >> 
3.10 The Ratfor Macro CCL 

<< block >> 
Ratfor contains a macro processor. It is useful for simple character ENDCC 


string replacements, string replacements with parameters, as well as 
for powerful extensions of the Ratfor syntax. Macros are defined with 


; There is no need to use all three conditions (CCE,CCG,CCL). If one is 
the DEFINE statement. In the following we give a few examples of 


omitted, control continues for that case after the ENDCC. The sequence 


simple macro definitions. of CCE,CCG and CCL may be chosen arbitrarily. 
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4. Our RATFOR/3000 implementation 


Our RATFOR implementation was derived from a RATFOR preprocessor ori- 
ginally written for the HP1000 family of computers. Therefore it is 
capable to produce output for the HP1000 FIN-IV compiler as well as 


for FORTRAN/3000. 
RATFOR/3000 may be invoked by the following UDC: 


For PORTRAN/3000: 
RATFOR <in>,<out>,<list>,<opts>,<incld>,<ftnlist> 


Por PIN4/1000: 
RAT4 <in>,<out>,<list>,<opts>,<incld>,<ftnlist> 


the Ratfor program will be read from <in> (default SNULL) 


the intermediate Fortran code will be written to <out»>» 
(the default is a SESSION temporary file RATTEMP ) 


the source listing will be written to <list> (default SSTDLIST) 
options are specified by <opts> (default %17 or %13) 
The options are given as an integer constant (octal or decimal). 
If the most significant bit is number O and the least signifi- 
cant is number 15, the bits have the following meanings: 
15 list the source, otherwise only errors are listed. 
bit 15=0 is automatically set, if <list>» = SNULL; 
errors are then output to SSTDLIST. 
14 for future enhancements 
13 «=1 FORTRAN/3000 code 
=0 FTN4/1000 code 


automatically set by the two UDC's 


12 merge all RATFOR (and other) comments into the generated 
FORTRAN program 


the file <incld> will be included in fre..c +f <in> (default SNULL) 


the FORTRAN compiler listing will go to <ftnlist>» (default SSTDLIST) 
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4.1 Limitations 


Due to the fact that this version of RATFOR is an adaptation from the 
HP1000 version there were some features in RATFOR/1000 that did not 
conform with FORTRAN/3000 syntax. Therefore, if in HP3000 mode some 
original RATFOR features are switched off. In particular, in HP3000 
mode the following applies: 


1. CHARACTER declarations are passed as they are, because 
PORTRAN/3000 supports type CHARACTER variables. 


2. Character strings between quotes, e.g. "ABCDEF", are kept as they 
are. In non-HP3000 mode this is converted to 8SHABCDEF. 


To allow for the use of substring designators, e.g. I[{3:5], in both 
modes brackets are not recognized as delimiters of blocks as they were 
in the original version. Use braces "{}" instead! 


RATFOR ‘does NOT understand FORTRAN arithmetic IF statements. If you 
have to use them, e.g. to check the condition code after returning 
from a system intrinsic, you have to put the statement between quotes. 
(There is a special RATFOR macro available to check condition codes) 


For FORTRAN/3000 applications it is good practice to use the following 
compiler command: 


SCONTROL USLINIT, NOSOURCE 


If you then use the default setting for the FORTRAN/3000 output 
(SSTDLIST) you will not get the awkward FORTRAN listing, but instead 
all (if at all) error messages with the line in error on your 
terminal. The FORTRAN line numbers are derived from the original 
RATFOR source line numbers, with an increment of .001 if there are 
more than one FORTRAN lines generated from one RATFOR line. Therefore 
it should be easy to find the RATFOR line, which is in error. 


5. Conclusion 


In conclusion, we found the RATFOR preprocessor a very valuable pro- 
gramming tool, especially since a FORTRAN-77 version for the HP3000 
seems to be still far away. Although FORTRAN-77 adds some of RATFOR'S 
control structures, we find the cosmetics, the appearance of the pro- 
gram text, of RATFOR much more appealing. 
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Now, what is the pay-off? Certainly compilation time is increased. In 
the current version, the RATFOR compiler needs about the same CPU time 
to transform RATFOR to FORTRAN as_ the FORTRAN compiler needs for its 
job. This can be somewhat improved in the future by sampling the most 
frequently used parts of the preprocessor and improving on these 


pieces of code. 


In addition you have to be aware, that RATFOR/ 3000 checks only RATFOR 
syntax, most of the FORTRAN statements go unchecked to the FORTRAN 
compiler. FORTRAN/3000 will then give you the errors. Since the kine 
numbers of the intermediate FORTRAN code a derived from the original 
RATFOR line numbers, it is very easy to track an error reported by the 
FORTRAN compiler back to the original RATFOR source line. 


Regarding run-time performance, we aid not find any significant 
@ifference between a RATFOR program and a corresponding version 
written directly in FORTRAN. 


Of course, a globally optimizing FORTRAN compiler, which we are all 
waiting for, would improve the run-time behaviour of RATFOR programs 


as well as FORTRAN programs. 


[1] B.-W. Kernighan, . P.J. Plauger: Software Tools, Addison-Wesley 
Publishing Co. 1976 
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BUDGETING AND PROFIT PLANNING ON THE HP3000 


BY JACK DAMM, PRINCIPAL, THE PALO ALTO GROUP, CUPERTINO, CALIF 
(408) 725-1282 


Good morning. Today I'm going to talk about budgeting and 
profit planning on the HP3000. This discussion will be 
organized around a specific example, but will not be limited 
to it. This is a very subjective discussion. There is cer- 
tainly plenty of room for conflicting opinions. And there 
are many ways of putting together plans which are different 
from the example being presented here. 


How many of you in the audience have the primary respon- 

sibility for budgeting or profit planning in your company? 

How many of you are in your company's data processing department? 
How many of you get no closer to profit planning than putting 
together your own budgets? 


I hope that when this discussion is finished, that as a "D.P. 
person" you get a little better idea of what overall company 
planning is, and where your own budgeting and forecasting 
fits into it. As a "financial planner", I hope that you will 
leave with a better understanding of the the HP3000 can con- 
tribute to your own company's planning. . 


My discussion will proceed as follows: First, some gener- 
alities about planning. The use of the HP3000. 

A brief comparison of high-level financial planning lang- 
uages versus manual or programmed models. Then I will 
discuss a typical plan. 


First, a definition. 

When I talk about planning, I will be speaking specific- 

ally about company (or corporate) planning. Product fore- 
casting, departmental budgeting, and financial projections. 
Deciding where funds are to be spent, and analysing the impact 
of these expenditures. 


There is a myth: That one can build a “model" of a 

company which can be mathematically manipulated to make 
“optimal” use of resources and maximize achievement of 
company goals. That this model needs to be complicated, and 
is incomprehensible to mere mortals. It is true that one 
could formulate a “model” of a company where the goal is to 
maximize profit or cash flow, with constraints involving 
debt-to-equity ratios, market penetration, production capa- 
city, etc. But because of how little we actually know about 
the future, and how much uncertainty there is about it, to 
build a sophisticated model which "optimizes" the results of 
a business, is ridiculous. It would be fooling ourselves 
about how little we actually know. 


There is reality: What planning really is, is sitting down and 
accepting that there is much uncertainty about the future. 

But at the same time, in order for us to be somewhat prepared 
for that uncertain future we must make assumptions. Best 
guesses about what may happen. One of the most important 
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results of the planning process is to get managers 

together and come to a general agreement as to how company 
goals are to be achieved. In a nutshell, planning is sit- 
ting down with marketing and production planning people 

and getting a “best guess" product forecast. Getting respons— 
ible managers to commit to realistic levels of spending 

within their departments. Create a plan of action which 
represents a generally agreed-upon approach to the direction 
of the business. 


While it may be uncertain, a good plan at least makes it 
possible to rule out the "unlikely" or "infeasible" situation 
which might result from “seat-of-the-pants" guesses: 


- Growing too fast to be supported by available funds 
- Spending too much money to have any left over 

- Selling more product than can be produced 

- Producing more product than can be sold 


So, I am going to talk about reality. Putting together a 
plan, what it means, and how the HP3000 can be used as an 
effective tool in getting the job done. 


THE TOOLS: An HP3000 computer system, available for both 
batch and interactive use. Most of our customers use in-house 
(rather than dial-up) systems. They use both on-line CRT's 
and printing terminals, and most have access to a near-by 
line printer. The system is almost always accessible to the 
responsible manager, although some companies distribute only 
the reports and not the computer interaction as well. The 
system is used interactively for setting up reports and re- 
viewing the results on a particular report. Reports are — 
run in the batch mode for making multiple copies, generating 
a whole sequence of reports at once, and sometimes just for 
hard-copy output. 


A high-level planning language. We work with our proprietary 
financial planning language, Dollar-Flow, and it will be used 
to illustrate the examples here. We choose to work ina 
"high-level language" like Dollar-Flow because: 


- Planning by hand (and calculator), despite the flexib- 
ility it provides, takes too much time, involves too 
many opportunities for error, and is particularly 
undesirable when doing many iterations of a plan. 

- Planning on a computer using a “procedure level" 
language like BASIC, FORTRAN, or COBOL takes too 
long to set up, is inflexible, and requires the 
services of a programmer. 


Dollar-Flow, because it is designed for planning, enables us 
to focus on the problem itself, without paying particular re- 
gard to all the details of what is actually going on in- 

side the computer. 


THE PLAN: A typical financial plan might involve the follow- 
ing modules: 


- A sales foecast 
- Budgets and budget consolidations 
- A profit/loss projection 
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- A cash flow projection 
- A balance sheet projection 


Most of the plans which we get involved with work on a three 
to five year horizon with (of course) particular attention 
being paid to the first year. For the first two years the 
plan usually is done by month, whereas the third through 
fifth year projections might be by quarter, by half, or on 
an annual basis. 


SALES FORECAST: Preparing the sales forecast is the first 
step in profit planning. Today I am not going to go into the 
any techniques which can be used for forecasting. Rather, I 
am going to concentrate on the techniques we use for working 
with forecast figures which have been decided upon (in one 
way or another) by those responsible for the forecast. 

The sales forecast is the most important as well as the most 
uncertain part of the planning process. Since sales de- 
termine how much money is available for budgets, etc., the 
forecast is prepared first. And because of the uncertainty 
of our projections, we may re-run our plan several times with 
varying levels of sales as a "what-if" analysis. So we can 
do contingency planning. 


A forecast for a product-oriented company is usually done 
first on a "bottoms-up" basis. That is to say, on a product- 
by-product basis. If we are building a plan with a three or 
five year horizon, the third through fifth years may only be 
overall sales dollars estimates. In the near term, however, 
the sales forecast is done by month for each product. In 
addition to the unit sales forecast, we need an average 
selling price on each product (which may vary over time), 
which we will show as one value here. And to enable us to 
generate figures for the cost of sales, we combine this data 
with estimates of direct labor per unit, direct material per 
unit, and manufacturing overhead (which may or may not be on 
a per-unit basis). The sales revenue and cost of sales 
forecast then is simply a product of the unit sales project- 
ions and the per unit price and cost factors. A typical 
product forecast might look like the following: 


12/ 4/79 XYZ COMPANY PAGE 
SALES FORECAST REPORT 
AVG DIRECT DIRECT MFG 
SELLING LABOR/ MATL/ OVHD/ 
PRICE UNIT UNIT UNIT 
1 WIDGETS... . cece cece 900 85 200 255 
2 GIZMOS.. @eeeeee%e#eeees¢ eee 1,300 155 275 465 
3 THINGS. ce cccvccvccses e l, 950 175 375 525 
4 NON-THINGS. eooeev eevee 2, 100 575 525 1,725 
5 ZITHERS. @eeeeeeeee*# ° 2; 450 560 450 1,680 
JAN JAN REV JAN DL JAN DM JAN OVHD 
UNITS 
1 WIDGETS......... 100 90,000 8,500 20,000 25,500 
2 GIZMOS... cece 50 65,000 7,750 13,750 23, 250 
3 THINGS. eee e ee ee @ - - - _~ _ 
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5 ZITHERS....ccccccce rex — —, - -_= 


6 TOTAL ALL PRODUCTS. 175 207,500 30,625 46,875 91,875 


Now, a top-down analysis may be done on the total sales figures 
in each period (or by year) and feedback on the unit forecasts 
if they are too high (or low). 


In businesses which build product to inventory (where sales 

and production levels may be very different in a given period), 
a manufacturing plan is required in addition to the sales 
forecast. That is to say, once the sales forecast has been 
prepared, then the production planners must sit down and de- 
termine a production plan which will meet an objective level 
of delivery of product and reasonable levels of inventory, 
given the sales forecast. The production plan would be 

similar to the unit sales forecast - it is simply the units 

to be produced by period. The result of the production plan is 
actual outlays for direct material and direct labor (which 

go into inventory). Combined with the cost of sales (what 
comes out of inventory) this gives us the change in invent- 
ories. A typical production plan might look like the following: 


12/23/79 XYZ COMPANY PAGE 1 
PRODUCTION PLAN 

JAN FEB MAR APR MAY 

6 TOTAL SALES..... weceeceee 207,500 207,500 207,500 467,500 461,000 


7 TOTAL COGS LABOR........ 30,625 30,625 30,625 53,000 52,225 


8 TOTAL COGS MATL......... 46,875 46,875 46,875 96, 250 94,875 


9 TOTAL COGS OVHD.......---. 91,875 91,875 91,875 159,000 156,675 
10 TOTAL COGS..... core ones » 169,375 169,375 169,375 308,250 303,775 
ll WIDGET UNIT PRODUCTION.. 100 100 100 100 100 
12 GIZMO UNIT PRODUCTION... 50 50 25 20 10 
13 THING UNIT PRODUCTION... - 50 100 150 150 
14 NON-THING 

UNIT PRODUCTION......... 25 25 25 25 25 
15 ZITHER UNIT PRODUCTION.. - = ~ - 10 
16 TOTAL 

PRODUCTION (AT ASP)..... 207,500 305,000 370,000 461,000 472,500 
17 TOTAL PROD LABOR........ 30,625 39,375 44,250 52,225 56,275 
18 TOTAL PROD MATL.......2e-. 46,875 65,625 77,500 94,875 96,625 
19 TOTAL PROD OVHD......... 91,875 118,125 132,750 156,675 168,825 
20 TOTAL 

PROD LABOR,MATL, OVHD.... 169,375 223,125 254,500 303,775 321,725 
21 PROD MATL PURCHASES..... 77,500 94,875 96,625 131,625 130,250 
22 INITIAL INVENTORY....... 125,000 
23 BEGINNING INVENTORY..... 125,000 155,625 238,625 342,875 375,150 
24 INVENTORY CHANGE...... «+» 30,625 83,000 104, 250 32,275 oy Brees i 5, 
25 ENDING INVENTORY........ 155,625 238,625 342,875 375,150 426,725 


* END OF S$FLOWS REPORT * 


Now, we are not finished with the forecast. One is never 
finished with the forecast. But with it set up in our 
planning system as we are doing here, when the forecast 
figures change, we can re-run our model and get a revised 
company plan with a minimum of effort. 


The next step is budgeting (which may overlap with the 
forecasting step). The forecast is important to the budget- 
ing step because it tells us how much is available to be 
spent in the budget. In other words, the budgets may need 
to be revised as the forecast changes. 


A few comments about the typical budget environment. 
- There is usually a budgeting hierarchy, where there 
are several levels of consolidation. Budgets may be 
grouped at sub-department, department, product line, 
division, or many other levels. 
- In addition to the consolidation hierarchy, there 
may be service departments (or locations) which charge 
some costs out to other departments (data processing 
for example). 


A typical budgeting hierarchy might have the following 
levels: 
Overall company budgeted expenditures 
Divisional consolidated budgets 
Product line consolidated budgets 
Departmental budgets 
Location budgets (within a department) 
Service location budgets 
Now, the budget reports we usually set up identify each bud- 
getary item by general ledger account number and description. 
For most. of the items on the budget, the system prompts for a 
value to be input for each period on the budget (typically the 
periods are months) and allows for revisions to be made by row 
and/or column. Typical input lines are: 
1001 WAGES & SALARIES 
3001 SUPPLIES 
5002 COMPANY AUTO 
5003 ENTERTAINMENT 


Some budget items are functions of other items. For example, 
fringe benefits may be set up as 20% of wages and salaries: 


1002 FRINGE BENEFITS = .20 X ‘1001 WAGES & SALARIES' ; 


The total budget may be calculated using the '‘SUM' function of 
Dollar-Flow: 


TOTAL BUDGET = SUM('1001 WAGES & SALARIES','9999 MISC EXPENSE'); 


And some budget items may use figures allocated from other 
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ocations: 


3005 EDP EXPENSE = 


could define a consolidation report as summing 'D900#' which 
would automatically add up 'D9001' through 'D9009'. 

Budget consolidation reports usually have the same format as 
the lower-level reports they reference. 


'S EDP ALLOCATION' X ‘TOTAL BUDGET' OF 'N9000'/100; 
A few comments about the budgeting process. In our experience 
A typical budget plan might look like: we have seen great diversity in how companies do their plan- 
ning. Some companies centralize budget preparation. Distri- 
12/23/79 MARKETING BUDGET PAGE 1 buting budget worksheets, then inputting the data and making re- 
FY 1980 visions in one area. Other companies distribute the entire pro- 
cess, letting managers interact directly with the budget system, 
‘TAN FEB MAR APR MAY only processing the data when it is ready for consolidation. 
Some companies budget in great detail. Others take the "big 
1 1001 WAGES & SALARIES 5000 5000 5000 10000 10000 picture" approach, working at higher levels of consolidation. 
2 1002 FRINGE BENEFITS 1000 1000 1000 2000 2000 The one thing that all of the companies which we have worked 
3 1003 PAID VACATION 100 100 100 200 200 with have in common, is that the budgeting process involves many 
4 1004 SICK PAY 150 150 150 300 300 changes and several iterations. With several levels of consoii- 
5 3001 SUPPLIES 500 500 500 500 500 dation, and allocations from several service departments, 
6 3005 EDP EXPENSES 800 800 800 1200 1200 budgeting would be a massive job if it were done by hand. And 
7 5001 TRANSPORTATION FARES 2000 2000 2000 2000 2000 a massive headache if it were done with the traditional program- 
8 5002 COMPANY AUTO 500 500 500 500 500 ming approach in BASIC, FORTRAN, or COBOL. 
9 5003 ENTERTAINMENT 500 500 500 500 500 
10 8001 ADVERTISING 1000 1000 5000 2000 2000 Once the budgets have been prepared, we are ready to proceed 
11 8002 PROMO LITERATURE 2500 2500 2500 2500 2500 with the profit/loss projection. With the information provided 
12 8003 TRADE SHOWS 10000 - - 20000 - by the sales forecast and manufacturing plan, plus the depart-— 
13 9999 MISC EXPENSE 500 500 500 500 500 mental budgets, the P & L is little more than a recap of exist- 
soshestuerteatentaatetitliententantentestentatitectentestastentesteattttieatetentetesteteatttietetentetetenten ing information. This is particularly easy in the system which 
14 TOTAL BUDGET 24550 14550 18550 42200 22200 we are using because we can ‘define’ relationships on our P & L 
15 % FRINGE 20.0 3% report which will cause data to be read automatically from re- 
16 % EDP ALLOCATION 8.0 &% ports which have already been prepared. For example, we could 


read information from the manufacturing plan with rules like the 
* END OF S$FLOWS REPORT * following: 
DIRECT LABOR = ‘TOTAL COGS LABOR' OF 'MFGPLN' ; 


By having allocated expenses defined within our planning 
DIRECT MATL = 'TOTAL COGS MATL' OF ‘'MFGPLN' ; 


system as automatically flowing into each of the using loca- 
tions, it is easy for us to keep all of the budgets con- 
Sistent. Whenever the budget for a service department (such 
as EDP) is revised, the new figures flow into the departments 
using their services the next time those budgets are run. 


where 'TOTAL COGS LABOR' and 'TOTAL COGS MATL' are lines on the 
production plan which has been set up and saved under the name 
"MFGPLN'. 

We can even reference several reports for a one-line consoli- 


One more comment about the system we are using. Within 


Dollar-Flow, information is organized on a report basis. That dation: 
is to say, users work with one report at a time and do not 
have to concern thenmselves with the distinctions between MARKETING = ‘TOTAL BUDGET' OF (‘'D2001','D2002',...,'D2009'); 


reports, files, programs, and data. And reports are saved 
on the HP3000 under 8 character MPE file names so they 
referenced by other reports and/or re-run at some later time. 


Of course the one-line consolidation shown here would only be 
necessary if we didn't have a consolidation report already 
set up for total marketing. 

We usually organize the budget reports according to the 
customer's own scheme for identifying budget locations, by 
saving these reports with meaningful names. For example, if 
the EDP department has a location code number of 9000, then 


A few of the lines involve calculations with other lines on the 
P & L report itself: 


we might save the budget for that department under the name TOTAL DIRECT COST = 'DIRECT LABOR' + 'DIRECT MATL' + 'MFG OVHD' ; 
"D9000'. Sub-departments locations might be coded 'D9001', GROSS MARGIN = 'SALES' - 'TOTAL DIRECT COST’ ; 
*D9002', etc. A budget which is a consolidation of other 


And one line, ‘INTEREST EXPENSE', is a forward reference to two 


departments might be stored with a descriptive name like 
other lines yet to be defined: 


D900' or 'D900X'. With a numbering scheme which groups 
various budgets into group names which can be accessed using 
@, #, and ? symbols (according to the MPE file referencing 
convention), indirect file references can be used to set up 
the structure of a budget hierarchy. In other words, we 


INTEREST EXPENSE = ‘'% INTEREST' X 'OUTSTANDING DEBT' / 1200 ; 


Now, the P & L projection (combined with the cash flow) is 
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usually run as soon as the first pass forecast and budget reports 
are ready. The budgets and the forecast are then red-lined, and 
sent back for revision. The revisions may involve changes in 
budgeted expenditures, pricing (and volume) of products, or even 
timing of product introduction and related expenditures. The 
running of the P & L and the cash flow is then the "top-down" 
step in planning, where the forecasts and budgets are revised 
based on overall criteria. 


A typical P & L projection might look like the following: 


12/23/79 YYZ COMPANY PAGE 
PROFIT/LOSS AND CASH FLOW PROJECTION 
JAN FEB MAR APR MAY 
1 PROFIT/LOSS PROJECTION: 
2 SALES 207.5 207.5 207.5 467.5 461.0 
3 DIRECT COSTS: 

4 DIRECT LABOR 30.6 30.6 30.6 53.0 52.2 
5 DIRECT MATL 46.9 46.9 46.9 96.3 94.9 
6 MFG OVHD 91.9 91.9 91.9 159.0 156.7 
7 MFG OVHD VARIANCE (1.9) (28.1) (42.8) 13.3 1.2 
8 TOTAL DIRECT COST 167.5 141.3 126.6 321.6 305.0 
9 GROSS MARGIN 40.0 66.3 80.9 145.9 156.1 
10 ENGINEERING 25.0 25.0 25.0 35.0 35.0 
11 MARKETING 24.6 14.6 18.6 42.2 22.2 
12 GEN & ADMIN 25.0 25.0 25.0 25.0 25.0 
13 TOTAL PERIOD EXPENSE 74.6 64.6 68.6 102.2 82.2 
14 OPERATING PROFIT (34.6) 1.7 12.3 43.7 73.9 
15 INTEREST EXPENSE 9 2.0 - - 2.3 
16 NET INCOME BEF TAX (35.5) C23.)-- 1233 43.7 71.6 
17 TAXES ON INCOME - - - 9.8 34.4 
18 NET INCOME AFTER TAX (35.5) (sa) 12.3 34.0 37.2 


For companies where cash flow is important (because they are 
growing rapidly, because margins are low, or a host of other 
reasons), the cash flow projection may be the most important 
part of the planning cycle. 


Now, setting up a cash flow projection from the information we 
already have available requires little more than taking our P & L 
results and adjusting them for timing in the flow of funds. 

Let's start this with a very simplified rule of thumb. The dif- 
ference between profit and cash flow is that: 


PROFIT (like your salary) is what you pay taxes on, whereas 
CASH is what you have in the bank. 


And we all know what a big difference that can be! Let's examine 
two important examples. If a company sends a shipment to a cus- 
tomer along with a bill for the goods, then the amount of the 
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bill (less the cost of making the goods) is profit. However, 
all the company who shipped the product has at this point is a 
thing called "accounts receivable", or money owed to it by the 
customer which has not yet been paid. This becomes cash only 
when the customer pays his bill. Conversely, when a company 
takes delivery of goods on credit from a vendor, the amount owed 
to the vendor ("accounts payable") only becomes a cash outflow 
when the bill is paid. In both of these cases, cash will even- 
tually change hands to offset accounts receivable and accounts 
payable. However, the timing makes a big difference in cash 
flow. And, keep in mind, running a business at a loss (although 
undesirable) is not nearly as serious as running out of money 
(and unable to borrow it somewhere)! If a company is growing 
fast, it is very easy to run out of cash even though the busi- 
ness is very profitable. 


Enough of the generalities. Let's look at what we do to create 
our cash flow. First, the "aging" of accounts receivable, or 
reflecting how cash payment of accounts receivable is expected 
to occur over time. We usually calculate a 3 month moving aver- 
age of sales, then use an estimate of the number of days of sales 
that will be in accounts receivable at one time. We set up this 
number of days sales figure as an easily revised input value so 
that the plan can be run at varying rates of receivables collec- 
tion. Combining the average sales with the number of days sales 
which are in accounts receivable, we project the ending accounts 
receivable balance for each month. With this information, all 
we have to do is a calculation with the following rule to deter- 
mine cash receipts: 


RECEIPTS = ‘BEGINNING A/R' + '‘SALES' ‘ENDING A/R' ; 


The report lines appear as follows: 


JAN FEB MAR APR MAY 
21 CASH FLOW PROJECTION: 

22 RECEIVABLES AGING: 

23 PRIOR 2 MOS SALES 180.0 190.0 _ - - 

24 3 MOS AVG SALES 192.5 201.7 207.5 294.2 378.7 
25 # DAYS SALES IN A/R 45.0 45.0 45.0 45.0 45.0 
26 BEGINNING A/R 300.0 288.8 302.5 311.3 441.3 
27 CHANGE IN A/R (11.3) 13.8 8.8 130.0 126.8 
28 ENDING A/R 288.8 302.5 311.3 441.3 568.0 
43 RECEIPTS 218.8 193.8 198.8 337.5 334.3 


For accounts payable, the process is a little more involved. 

We take the total budgeted expenditures for all of the operat- 
ing departments and subtract out the payroll and depreciation 
expenses from them. We add into this direct material purchases 
and capital equipment purchases. This gives us the amount of 
accounts payable we have incurred. Then, we assume that all of 
our bills are paid in 30 days (or 1 period in the example here). 
So we just take the prior period's accounts payable to determine 
Our payment of accounts payable in the current period. To han- 
dle the first period, we add a figure for accounts payable in- 
curred in the preceding period. This analysis appears as follows: 
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29 PAYABLES AGING: 


30 BUDGETED EXPENSES 164.6 154.6 158.6 272.2 252.2 
31 PAYROLL 50.0 60.0 65.0 75.0 80.0 
32 PAYROLL (EXCL D.L. ) 19.4 20.6 20.8 22.8 23.7 
33 DEPRECIATION 7.0 7.0 7.0 7.0 7.0 
34 MATERIAL PURCHASES 77.5 94.9 96.6 131-6 130.3 
35 CAPITAL EQUIPMENT PURCHASES - - - 200.0 - 
36 ACCTS PAYABLE INCURRED 215.7 221.8 227.4 574.1 351.7 
37 PRIOR PERIOD A/P 190.0 

38 ACCTS PAYABLE PAID 190.0 215.7 221.8 227.4 574.1 


For interest payments, we assume that they are paid in the per- 
iods that they are incurred. (We will discuss the interest cal- 
culation in somewhat greater detail in a moment.) And taxes are 
usually paid based on the results of the prior year. In the 
example here, we have assumed that no taxes were due in the 
preceding year. 


Now, to calculate the cash flow in each period, all we do is to 
take the receipts and subtract the total of payroll, accounts 
payable paid, taxes paid, and interest paid. This gives us our 
net cash flow from operations in any given period. 


42 CASH FLOW: 


— oe een ee ee oe eee 
— oe ee oe ee ee eee oe 


43 RECEIPTS 218.8 193.8 198.8 337.5 334.3 
44 DISBURSEMENTS: 
45 PAYROLL PAID 50.0 60.0 65.0 75.0 80.0 


46 ACCTS PAYABLE PAID 190.0 215.7 221.8 227.4 574.1 
47 TAXES PAID = 
48 INTEREST PAID 9 2.0 = = 2.3 


49 TOTAL DISBURSEMENTS 


50 NET CASH FLOW (22.2) (83.9) (88.1) 35.1 (322.1) 
Next, we consider financing. As shown here, we have constructed 
a model which takes the beginning balance of cash in a given 
period and adds into it the changes in cash due to operations. 
Equity financing is then added into the cash balance. Then, we 
set up a rule for the line ‘BORROWING (REPAYMENT )' which says 
"Tf the cash balance is less than zero, borrow enough money to 
bring the balance back to zero. If the cash balance is greater 
then zero, then pay off any existing debt with whatever cash is 
available." We then add this borrowing or repayment into our 
cash balance and we have ending cash for the period. The 
financing lines appear as follows: 


51 BEGINNING CASH 50.0 = - 105.9 141.0 
52 CHANGES IN CASH (22.2) (83.9) (88.1) 35.1 (322.1) 
53 ENDING CASH 27.8 (83.9) (88.1) 141.0 (181.1) 
54 FINANCING = = 350.0 = = 
55 BORROWING (REPAYMENT ) (27.8) 83.9 (156.0) ss 181.1 
56 ENDING CASH AFTER FINANCING = = 105.9 141.0 = 
57 BEGINNING DEBT 100.0 72.2 156.0 = - 
58 OUTSTANDING DEBT 72.2 156.0 = 181.1 


59 % INTEREST PAID 15.0 % 15.0 % 15.0 $15.0 % 15.0 % 


One last comment about the cash flow. The ‘INTEREST EXPENSE’ DS ll 
line on the P & L statement is calculated using the ‘'% INTEREST 


PAID' and ‘OUTSTANDING DEBT' lines on the cash flow. The system 
which we are using actually solves the circular logic involved 
in calelating interest, cash flow, and debt, so that these 
values are all mutually consistent. 


The last step in our profit plan is the creation of a balance 
sheet. Similar to the P & L statement, the balance sheet is 
usually just a recap of the P & L and cash flow projection. I 
won't say much about the balance sheet, except to mention that 
we use it as a tool to make sure that our cash flow projections 
are working correctly. If our assets are equal to our liabili- 
ties (as they should be), then we can be pretty sure that we 
haven't made a mistake in the general logic of the cash flow (of 
course the values could still be wrong!). The balance sheet 
might appear as follows: 


12/23/79 XYZ COMPANY PAGE 1 
BALANCE SHEET PROJECTION 
DEC JAN FEB MAR APR MAY 

1 ASSETS: 

2 CASH 50.0 - - 105.9 141.0 - 

3 ACCTS RECEIVABLE 300.0 288.8 302.5 311.3 441.3 568.0 

4 INVENTORY (NET) 125.0 155.6 238.6 342.9 375.2 426.7 

5 TOTAL CURRENT ASSETS 475.0 444.4 541.1 760.0 957.4 994.7 

6 PROP, PLANT & EQUIP 2255.0 2248.0 2241.0 2234.0 2427.0 2420.0 

7 TOTAL ASSETS 2730.0 2692.4 2782.1 2994.0 3384.4 3414.7 

8 LIABILITIES AND NET WORTH: 

9 ACCTS PAYABLE 190.0 215.7 221.8 227.4 574.1 351.7 
10 TAXES PAYABLE - - - = 9.8 44.1 
11 S.T. BANK LOAN 100.0 72.2 156.0 - - 181.1 
12 TOTAL 

CURRENT LIABILITIES 290.0 287.8 377.8 227.4 583.8 576.9 
13 L.T. BANK LOAN 900.0 900.0 .900.0 900.0 900.0 900.0 


14 TOTAL LIABILITIES 1190.0 1187.8 1277.8 1127.4 1483.8 1476.9 
15 STOCKHOLDERS EQUITY: 
16 COMMON STOCK 


17 RETAINED EARNINGS 


2340.0 2340.0 2340.0 2690.0 2690.0 2690.0 
(800.0) (835.5) (835.7) (823.4) (789.4) (752.2) 


18 TOTAL 
STOCKHOLDERS EQUITY 1540.0 1504.5 1504.3 1866.6 1900.6 1937.8 
19 TOTAL LIABS & WORTH 2730.0 2692.4 2782.1 2994.0 3384.4 3414.7 


20 ASSETS - LIABS - - - és es = 
* END OF $FLOW$ REPORT * 


This completes our profit plan. I want to emphasize here that 

the example we have used is not a fixed or canned example. De- 

pending on the way in which our customers think of their projec- 

tions, we may alter the rules for the P & L, cash flow, and 

balance sheet projections. And in most cases, the forecast re- 

ports and budgets are tailored to conform to the customer's own DS 12 


products and chart of accounts. The main idea here, however, is 
that we have a framework in which we set up analyses. Then, as 
required, we make changes taking advantage of the flexibility of 
the planning language which we are using. 


Setting up a realistic plan is an excellent first step in manag- 
ing a fast-moving business effectively, but it is only a begin- 
ning. What really counts is putting it into action. So, once a 
plan is established, then actual performance against it must be 
monitored. This can be done with a combination of budget var- 
iance reports, forecast versus actual sales reports, and com- 
parisons of P & L, cash flow, and balance sheet position. [In 
some cases, we set up variance reports within the Dollar-Flow 
system for this reporting. In other cases, we feed the projec- 
tions which have been set up in Dollar-Flow into other reporting 
systems. 


Let me summarize what we have covered here. Our overall company 
plan has encompassed a product-by-product forecast with a match- 
ing production plan to establish what we expect to produce and 
sell. We have established budgets which set the spending for 
various areas of responsibility in the company. And we have 

set up a profit/loss statement, cash flow projection, and balance 
sheet projection to examine the impact of the forecast and budgets, 
analyze alternative financing and management strategies, and to 
review the company operations on an overall basis. 


I hope we have eliminated some of the mystery and myth which sur- 
rounds the concepts of financial planning and cash flow analysis. 
Building an effective profit plan for a company is not a trivial 
task, nor is it an impossible one. We feel that it is an excel- 
lent opportunity to use the computer as a tool, but at the same 
time is not a good data processing application. Because of the 
demands in planning for flexibility, immediate feedback, ease of 
use, and good documentation, it is simply too difficult to set 
up good models in languages like COBOL, BASIC, or FORTRAN. With 
a good financial planning language, however, the HP3000 can be 

a very powerful tool for budgeting and financial planning. 


Thank you very much. Do you have any questions? 
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Umtroadwuction 


The Herbert Seitz Company is... 





C> A REALTIME DATAPROCESSING SERVICE BUREAU 
C> AND SOFTWAREHOUSE 
C> AND HEWLETT PACKARD OEM 









with (1981) 















C> 7 own up 3000 (series 111 AND 44) 
IN OUR BREMEN AND PFORZHEIM BRANCH 





Bremen 





c> AND 10 HP 3000 seERIES III IN 
ASSOCIATED COMPANIES 


WITH APPROX, 350 TERMINALS SPREAD 
OVER GERMANY CONNECTED VIA HARD- 
WIRED LEASED LINES/DIALED LINES 


"3 Pforzheim 


Location ol: 


o own Computers 





e Associated Companies 
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Lmtradmetion 


WE PROVIDE OUR SERVICES IN GERMANY AND FRANCE FOR COMMERCIAL 
APPLICATIONS LIKE .., 


a=) ACCOUNTING 
am) PAYROLL 
m= MATERIAL MANAGEMENT 


mw) SHOP FLOOR CONTROL, 
CAPACITY PLANNING 


= TOOLS FOR HP 3000 
OPERATION, SOFTWARE-DESIGN 
AND DOCUMENTATION 


OUR USERS ARE ..., 


=> WORKMEN 
=> DATA TYPISTS, CLERKS 
=> MANAGERS 


ONLY A FEW OF THEM ,., 


> ARE SPEAKING (HP-) ENGLISH 
> HAVE DP EXPERIENCE 
+> HAVE SEEN ANY TERMINAL BEFORE 
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OQ iT NS 


Introduction (ES: 


-) 


for this kind of users we need .... 


A FRIENDLY dmter€ace petweeNn THE USER AND 
HIS APPLICATION PROGRAMS 





Seas 
(C= EASY-TO-UNDERSTAND 


application 
programis 


auser training with 
REGARD TO THE STANDARD OF 
EDUCATION OF ITS PARTICIPANTS 







a 


Ce user documentation smanuats. 
WHICH INVITE TO READ 
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(I> KEEP YOUR USERS OUT OF MPE ! 


MPE IS A HIGH LEVEL OPERATING 
SYSTEM WITH A LOT OF POWERFUL 
COMMANDS. BUT IT IS NOT DESIGNED 
FOR THE DIRECT USE OF USERS WE 
ARE DISCUSSING ABOUT 


a 


(WE CALL OURS 
"USER-PROFILES” ) 
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INTERFACE (3) 


[> THE USER ONLY CAN DO THINGS YOU WANT HIM TO DO 
[> BUT HE CAN DO ANYTHING POSSIBLE WITH THE HP 3000 


AUSWAHLMENU °2 
QUERY WITH TERMINAL 7 
OUTPUT Be QUERY ohne LISTENAUFBEREITUNG 
QUERY WITH PRINT-OUTPUT 4 QUERY mit LISTENAUFBERETTUNG 
"ISTRY OF SOME FILES~~ Me ANZEIGE INHALTSVERZEICHNIS AUFBEREITETE LISTE 
04 DRUCKEN AUFBEREITETE LISTE 
HARDCOPY SPOOL PRINT 0S.= LOESCHEN AUFBEREITETE LISTE 
"PURGE. OF ONE FILE re DRUCKEN FAKTURIERUNG 
START OF A JOBSTREAM O07 = ZURUECK ZUM AUSWAHLMENU 1 


BITTE AUSWAHL EINGEBEN 





INTERFACE (2) 


=> WE ONLY NEED 1 MPE COMMAND: HELLO 
=> MENUES EASILY CREATED AND MAINTAINED WITH EDITOR IN ANY LANGUAGE 


FKUSWAHLMEHU 4 


~STUECTKLISTENVERWALTUHG C€P03201) 

AUF TPAGSVERWALTUNG CPO03202) 
TETLESTAMMVERWAL TUNG €H50001) 
ADRESSSTAMM-PFLEGE CADFOO1) 
AUFBERETITEN BETRIEBSAUFTPAEGE €P03203) 
FAKTURIERUNG C€P03207) 

PREITSLISTEN CP03206) 

NEURALKULATION ALLE ARTIKEL €P03205S) BANACH FCOPY ALTSEQ/ALTDAT 
PREIS ETIKETTEN 

BPITLLANTANFORDERUNG €P03208) 
FARTURIERUNG LIEFERSCHEINE €P03210) 
LAGERARTIKEL-STAMM-PFLEGE CPQO3211) 
SOFORT - FAKTURIERUNG CPO 3212) 


oe ee a 


> € 


2100 DB ta ty 


ty ah OED er FE 


(7 


AUSWAHLMENU 2 


339 = ARBEITSENDE 
BITTE AUSWAHL EINGEBEN 
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INTERFACE (5) 


=> ASK FOR RECONFORMATION OF CRITICAL CHOICES 


RECHENZENTRUM HERBERT SEITZ KG BREMEN - PFORZHEIM 
FINANZBUCHHALTUNG - DIALOG ( Auswahltabelle 4 ) 
€ Druck im Hause ) 
Drucken OP-Liste 
Drucken AP-Liste 
Drucken Personenkonten 
Drucken Sachkonten 
Drucken Journal 
Drucken Summensaldenliste 
Drucken Hauptbuch 
Drucken kumulierte Sachkontenwerte 
Drucken .Mahnungen 
Aufgliederung der offenen Posten 
Drucken Faelligkeitsliste 
Drucken Provisionsabrechnung 
= zurueck zur Auswahltabelle 1 
= Arbeitsende 
BITTE AUSWAHL EINGEBEN 
01 
bllenn Sie diese Arbeit wirklich wollen, 
dann wiederholen Sie bitte die Eingabe 
Imrer gewuenschten Auswahl. Andernfalls 
geben Sie ein beliebiges Zeichen ein. 


9M ZLISS LYaddaH WOYLNAZNAHOdd 





INTERFACE (4) 


Si 
secocoe 7g CONTROL OF REQUIRED SEQUENCE OF DIFFERENT MENUE-CHOICES REFERRING 
TO TIME, SITUATION OR KIND OF DATA-ENTRIES 


SI | 
“= INFORM THE USER WHAT THE COMPUTER IS DOING FOR HIM eeeeeccccoooosoooooooocclseceee 


O06 = NEUKALKULATION ALLE ARTIKEL CFPO3205) Bata Ge FCOFY ALTSEG/ALTDAT 
09 = PRETS ETIKETTEN 
> ERTLLANTANFORDERUNG CP0 3203) 
44 7 FAKTURTERUNG pet ER eS Bere CPO03210) 
420 = LAGERARTIKEL-STAMM-PFLEGE CPO3211) 
1 3 SOFORT - FAKTURIERUNG CP03212) 
14 RECHNUNGEN Tit RZ DRUCKEN 


16 = AUSHAHLINENU 2° 


94 = ARBEITSENDE 
BITTE AUSWAHL EINGEBEN 


OM ZLIGS DYAGNaH WNOULNAZNAHOTa 
@occcce 


; 


Die Rechnungen sind fer ig. Entscheiden Sie bitte, ob der Druck 


bei Ihnen oder im Rechenzentrum erfolgen soll und treffen die 
entsprechende Auswahl 3 = Pry b @ j hnen / 14 = Druck R< 





"YOUR INVOICES ARE READY, ENTER 13 FOR HARDCOPY OR 14 FOR LINE-PRINTER OUTPUT” 
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Application Pregrams 


-_ 
4 
ro 


GENERAL GUIDELINES FOR OUR PROGRAMMERS: 


Uapuamian 
Tyemnsny 
UBsUUdOY 


j= ONLY BLOCK MODE PROGRAMS (V/3000) 


JSQITS Yorts 
TAQGETTYeMsny 
TYEMSNY IW 
JIVVAYFILNI 


a=» TRY TO DESIGN GOOD READIBLE FORMS 


puts 


(9) 


uapuam yuyanyabsne 


YYoTU 4YTaZ uNz Uaytaquy auapue younp o4y3146n 
yapuauatuunyuoy uabam uuey ytaquy arrtysemaG arg 


<> AVOID (ENGLISH) ERROR MESSAGES FROM 
ANY HP SUBSYSTEM 





NSGS39ONI3 THYMSNY 31L1L1¢ 


jy ALWAYS POINT TO WRONG ENTRIES 
AND PROVIDE A MEANINGFULL 
ERROR MESSAGE 


WeMSny osSoTpP ot 
-uazz,easbamuty 


4232p 1tw auuads asatp ywaqan yots at 


oO 
= 
ce 
rd 
i) 
oO 
oO 
Mm 
a 
J 
om 
J 
QO. 
th 
) 
tf 
Oo 
M 
ma 
a 
5 
78) 
N 


<> ALLOW A REGULAR PROGRAM 
TERMINATION OR A CANCELLATION 
OF THE LAST ENTRY AT ANY TIME 
IN ANY SITUATION VIA THE 
F//F8 KEYS 


yonuqqewayisds yoru PERBERVESIIT) uy 
‘SdOrF YO SNOISSSS SAILIV YAHLO SV) 
SSILIAILOV ONILOINANOD ANV CIOAV 


a1S uaqgeb yaytamz wy. 
3 
auU] 4Vapatm ats uayTeyua rt 


j@e IF POSSIBLE, USE THE FIELDNAMES 
IDENTICAL WITH THE ITEM NAMES OF 
THE CORRESPONDING DATA BASE 


(‘Ola SHOr YO SNOISSAS YSHLO dO NOILSIdWOD WN4SS3DONS 


és» USE STANDARD FORMS AND TRANSACTION 
CODES IN ALL PROGRAMS AND SYSTEMS 


SOME EXAMPLES .., 
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APPLICATION PROGRAMS (3) 


LAGERBESTANDSF ORTSCHRE I BUNG RZ HERBERT SEITZ KG. 
INMBF 0 | PFORZHEIM - BREMEN 


MAN LAG MATERIAL-NR. ) 


038 IOS 1001 BI 


=: SHOW Aia-7-4-n86)| a ee AL UMIN LUM 
2GBES P= ARC DIN-BEZ. 


-SDIS ie eta. aeeeDELLVIERE S.A. ~ TNVENTUR-DAT. 
-INV ‘WeDI 


a=ENDE | Sila lea eal BESTELLBEST. DISPOBE ST AND GREIFB.BESTAND 


GESAMTLAGER ,000 2200 , 00¢ D0¢ 557 , 000-5 
EINZELLAGER 500. ,000 0,000 700, "000 200 ,000- 
Ps @) ry <2 - . . ee 

MENGE. | | —— NR’ BEST-NR . TERM -BETERM AUF-NR BS KTPD KZORPO5 


i . 3 


“DEN ERMINVORSCHLA UND ERGAENZI 


> qOVd 


"PLEASE CHECK THE SUGGESTED DELIVERY DATE AND COMPLETE THE ORDER” 


—_ 
em 


APPLICATION PROGRAMS (2) 





SAME TRANSACTION CODES IN ALL PROGRAMS 


LAGERBESTANDSF ORTSCHRE I BUNG | a RZ HERBERT SEIIz KG. 
INMBF 0 ae MPFORZHEIN - BREMEN 
MAN. LAG -MATERIAL-NR., S 


OsGMmCCOOMmAc2~34-001 TS 


“SHOW! Fie ZUG WERKSTOFF. 
DIN-BEZ 
LIEFERANT | ~ TNVENTUR-DAT. 


1 


7 . H 
GRUNDKALIBER 1177 


LAGERBESTAND BESTELLBEST. DISPOBESTAND GREIFB.BESTAND 


oe ee “GESAMTLAGER 4360 ,000 9321 ,000 15917,000 11557 ,000- 
“fge EINZELLAGER 500,000 § 0,000 700,000 200 ,000- 






SHOW - IF POSSIBLE - THE AVAILABLE TRANSACTION-CODES 


*aOVd 


et 
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*GdOWd 


SL 


*qOVd 


9L 





APPLICATION PROGRAMS vw, 
a a hi eater 


PROVIDE INFORMATIONS ABOUT LOCKS AND THEIR REASON 
Rechenzentrum H.Seitz 


VS TC IDTNR A Kopie von IDTKP Terminal 28 





KF6600 1 Teile - Stammdatenverwaltung 


EDK 2T 

LAGEP 
MK OSP 
INVPR 
DEIPR 
S7A 
S7B 


Aeine Aenderung moeglich. Das Terminal 71 hat das Teil im Zugriff 


"NO MASTER ITEM CHANGE POSSIBLE, THE TERMINAL 71 HAS EXCLUSICE ACCESS TO THIS ENTRY” 





APPLICATION PROGRAMS (4) 


TELL THE USER, IF A TRANSACTION TAKES MORE THAN THE NORMAL RESPONSE TIME 


tueck list .Verwal tgmys 


Pas. Fz Ident-Nr. ) Menge Me Vizt Kzf Pr Kost.st Liefer. Pt Bk 


Me Vlzt Kzf Pr Kost.st Liefer. Pt Bk 


"BILL OF MATERIAL WILL BE COPIED, PLEASE HOLD ON” 
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*gdOVd 


BL 








APPLICATION PROGRAMS (@) 


= HELP FACILITY AND FIELD EXPLANATION WITHIN PROGRAMS 


BESCHREIBUNG DES FELDES Qa) aus DEM TEILE-STAmmsaTz DESCRIPTION OF ExELD DISTU 
Aaya? FROM MASTERFILE 


DISPOSITION LEVEL 


DISPOSITIONSSTUFE 


FELDLAENGE 2 STELLEN, DAVON 0 DEZIMALSTELLEN, NUMERISCH renee 2, 0 DECIMALS, NUMERIC 
SeNDE RONG 1ST ERLAUBT. CHANGE 1S ALLOWED 
INHALT... =” ENDPRODUKT | _ 
pT eee) ae | | ALLOWED 1 = FINAL PRODUCT 
” * BAUGRUPPE | ENTRIES: 2 = ASSEMBLY 
= EINZEL- ODER KAUFTEIL 3 = PART OF PURCHASE ITEM 
HALBZEUG, ODER ROHMATERIAL 4 = RAW-MATERIAL 


%&k*& *& OUR EXPERIENCE: THIS FEATURE IS USED VERY SELDOM AND UT IS VERY EXPENSIVE 


TO DESIGN AND MAINTAIN 
WE DON’T EMPHASIZE IT IN ALL APPLICATIONS 


APPLICATION PROGRAMS (6) 


2 


FORCE USER TO CHECK HIS ENTRY, WHERE IT MAKES SENSE 


ELNGABESATZ2 ZUR. BUCHHALTUNG 


SA. 'BERATER OM MAND Gg  BUCH-DAT 


BUCHUNGS-DATUM 

KTO-NR.  UREFEEE) | H/S J) ST/SK-BET 

GEGKTO BV BELEGART BELEG-NUMMER (ee 

L.AUSNR AKZ % KOST KOST-TRAEGER 

VALUTA. FAELLKEIT BERLIN-HILFE > SCHECK 
SKTO-~PROZT SKTO-FAEL hia Machine ARTIKEL-GR FINANZPL 
ZAHL-ZIEL SONDERFELD SONFELD 2 al SKT..FAEH. BETRAG 


MENGEN-FELD rr RESERVE Co] 


Pruefen Sie bitte Ihre Buchung. 


#7 koennen Sie stornieren 


"PLEASE CHECK THE RESULT OF YOUR ENTRY. IF NECESSARY CANCEL WITH F7” 
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Wser raining 


OUR PROGRAM: 









>) INTRODUCTION INTO INTERACTIVE DATA PROCESSING 


<> UPDATE TRAINING FOR STANDARD USERS 





—) APPLICATION-TRAINING 


ae 
<> QUERY FOR NON-DP PERSONNEL 
ps ox om 
aoe 


<> UPDATE TRAINING FOR QUERY USERS 
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User TPraiming (2) 


INTRODUCTION TRAINING 


1/2 DAY THEORY, 1/2 DAY 
TERMINAL USE 
HARDCOPY-PRINTER USE 
HOW TO LOG ON 

HOW TO USE THE MENUES 
TRY SOME TRANSACTIONS 


HANDOUTS: 


7 SLIDE COPIES 

- TERMINAL AND HARDCOPY USER MANUAL 
(SIMPLIFIED AND TRANSLATED) 

- CHECKLIST FOR TROUBLESHOOTING 
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User Training (3) 


UPDATE TRAINING FOR STANDARD USERS 
“) REPEAT INFORMATIONS FROM INTRODUCTION AFTER SOME 
WEEKS/MONTH OF PRACTICE WITHIN 1 DAY THEORY 
=) HOW MTS WORKS 


“) HOW TO IMPROVE RELIABILITY OF DATA 
COMMUNICATION 











~) STRATEGIES FOR LESS RESOURCE- 
USAGE AND BETTER RESPONSE TIMES 






*) HELPFUL HINTS AND TRICKS 
FOR TERMINAL- AND HARDCOPY 
USAGE 












*) WHAT A COMPUTER HAS TO DO 
FOR A "SIMPLE TRANSACTION” 

(OR WHY DOES IT TAKE SUCH A 
LONG TIME) 


“) DIFFERENCES BETWEEN JOBS AND 
SESSIONS 


*) REASONABLE USE OF QUERY 


*) MORE INFORMATIONS ABOUT TROUBLESHOOTING 


SOME EXAMPLES «s+ 


E2 2] 


MLS Datentibertragune# 


RECHENZENTRUM 
BREMEN/ PFORZHE IM 


HP 3000 


POST STAND- 
*\LEIT TUNG 


1.TERMINAL 


2.TERMINAL 


. 3. TERMINAL 
Se 
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- DANACH ERFOLGEN EINE REIHE VON 


ZUGRIFFEN AUF IHRE DATENBANKEN, 
VOR UND NACH JEDEM ZUGRIFF MUSS 
IN EINER TABELLE DIE ENTSPRECHEN- 
DE KENNZEICHNUNS ERFOLGEN, DIE 
KONKURRIERENDE ZUGRIFFE REGELT. 
SIE KONNEN SICH DIESEN REGELUNGS- 
MECHANISMUS WIE EINEN POLIZISTEN 
VORSTELLEN, DER DEN VERKEHR AN 
EINER VERKEHRSREICHEN KREUZUNG 
MIT 20(!) ODER MEHR EINMUNDUNGEN 
REGELN SOLL 
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LISTEN SELBST GEMACHT - WIE FUNKTIONIERT DAS 2? 






DER ABRUF 
EINER LISTE 










DER “OFF- 
LINE DRUCK” 





MIT DEM LISTEN-ABRUF WIRD EINE PLATTENDATEI 
ERZEUGT (KEIN PAPIER BEDRUCKT) 







ERST DAS UFF-LINE DRUCKEN BRINGT DIE PLATTEN- 
DATEI AUF PAPIER 
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User Traiming (7) 


APPLICATION TRAINING 


CLASSROOM-TRAINING OR TRAINING ON THE JOB 
(KIND AND TIME DEPENDS ON APPLICATION) 


>) "TRAINING COMPANIES” FOR 
TEST AND TRAINING IN ALL 
APPLICATIONS 


=> FREE PHONE IN CONSULTING 
FOR ALL USERS 


ese RECHENZENTRUM HERBERT SEITZ KG PAGE: 25 





User Training (8) 


QUERY FOR NON-DP-PERSONNEL 


C> 3-4 pays WITH 7 LABS 
QUERY FoR USERS. ONLY INFORMATION RETRIEVAL 
(NO UPDATE AND DELETE) 

C> DATABASE. TERMS AND THEORY (VERY LITTLE) 


C’> HOW TO USE "HELP, FORM” 


[> SMALL REPORTS WITH 
"LIST" 


C> “FIND” COMMAND 


oe 0902 0te 
(OR HOW TO TRANSMIT ‘oO sD 6S 
MR. BOOLE’S MESSAGE ) as 


») 


[> COMPLEX REPORTS 





SOME EXAMPLES as. 
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004 
002 
003 
004 
005 


DATA SET NAME 

DATA ITEM NAME 

SETS 

ITEMS 

PATHS 
006 
007 


008 

RICHTIG FALSCH 009 

O44 

012 
013 
014 

FORM KDSTAM 015 
FOR-KDNR es 
Prom O18 
F ITEMS er 
020 

SETS FORM 024 
FORM ITEMS SETS ae 
023 

024 


25 


026 
027 
028 
035 
036 
037 
038 
039 


PROCEDURE: RPOi 


REPORT BEISPIEL 


yp _RPOg] 





R 
Hi, "AUFTRAGSUEBERSICHT VOM", 30 
Hi,DATE,40 


Hi, "SEITE", 60 
Hi ,PAGENO,6S,SPACE Ai 
H2,"AUFTRG",6 

H2, "DATUM", 43 
H2,"KDNR" ,49 

H2, "KUNDE" , 26 

2, "MENGE" ,54 
H2,"VK-PREIS",65 
H2, "AUFTRGS-WERT",78,SPACE Ai 

Gi, "ARTIKEL: ",8,SPACE H41,SPACE At ) Druck dee Ackkel-Nv 
G4i,ARTNR ,418 und Bereidaung bei 
G1i,ARTKBZ,29 Vener ArkkeR-Nre- 
T1i,R2 J Ld schon Rey. be neuer Art. Nr. 
Di,AUFNR,6 
Di ,AUFDAT, 13 

Di, KDNR,2 
Di, KDKEZ,2 

Di, AUFMENGE ,54,E4 

Ei, "ZZZZZZZ9" 

Di, ARTVKPR ,65,E2 


Ri,L,AUFMENGE Cerechuen Au ftrage wert 
R4i,M,ARTVKPR 

R2,A,R4i ¥ Kuurutieren Aut Fra g uert je Ackilek 
Di,Ri,78,E2 


E2,"ZZZZZ9.99" 
E3,"ZZZZZZZ9 .99-" 
T4,AUFNR ,&, COUNT 

Ti, "AUF TRAEGE" ,46 

Ti, AUFMENGE ,S4,E4,ADD 


040 T1i,R2,78,E2 
044 T4,ARTVKPR,65,E2,AVERAGE 
042 LINES=iS 
043 PAUSE 
044 Si,ARTNR 
045 END 
IMAGE / QUERY RECHENZENTRUM HERBERT SEITZ KG INMACE/CUERY RECHFEN2ZENTRUM HERBERT SEITZ KG PAGE: 28 
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User NecwmmMenktacionm 


=> STANDARD DOCUMENTATION FILES 
(FOR MANUAL PRINTING) ARE USER ACCESSIBLE 


=> USER MAY SUBMIT HIS ADD ON DOCUMENTATION 
INTO THE SAME DOC FILE 


(> =% MANUAL FOLLOWS THE TYPICAL PROGRAM 


SEQUENCE 


1\7 
=> ANY NEW INFORMATION ON THE 
SCREEN IS DISPLAYED WITH PICTURES 


SEE EXAMPLE NEXT PAGE ..- 


UFS2 RECHENZENTRUM HERBERT SEITZ KG PAGE: 29 
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- CHTL < CONTROL) 


- SHIFT-TASTE 


- LEERTASTE 


- DEL-TASTE 


- RETURN-TASTE 


GE-Ca 


01.10,79 


PERAK EE ics 


DIE CONTROL-TASTE WIRD ZUR UMKEHRUNEG YOR 
NORMALFUNKTIQHEN BZ. ZUR STEUERUNG VON 
SONDERFUNKTIOHEN VERWANDT. ZUR AUSFUEH- 
RUNG EINER SOLCHEN SONDERFUNKTION MUSS 
STETS DIE CONTROL-TASTE FESTGEHALTEN 
WERDEN UND EINE WETTERE ANDERE TASTE GE- 
DRUECKT WERDEN. SO IST 2Z.B. OIE CONTROL- 
TASTE FESTZUHALTEN UND DIE TAB-TASTE 2U 
BETAETIGEN, WENN NAN FELDWEISE RUECK- 
WAERTS SPRINGEH WILL. 


MIT DER FESTGEHALTENEN SHIFT-TASTE KOQEN- 
NEH DIE JEWESLS IM OQBERENH TASTENBEREICH 
ANGEZEIGTEN ZEICHEN EINGEGEBEN WERDEN. 
IM BEREICH DER BUCHSTABEH A - 2 DIENT 
DIE SHIFI-TASTE WIE DIE BUCHSTABEN-UN- 
SCHALTTASTE BEC SCHREIBHASCH 











STEVERUNG VON GROSSBUCHS TAP REGEL 
FALL «(ST JEDOCH DURCH DI IGU- 
RATION <CAPS-LOCK-TASY SHIFT- 
TASTE DER GROSSBUCHS IHGESCHAL- 
TET. 

OIE BREITE UHTEREN TASTATUR- 
BEREICH DY DER SCHREIBSMASCHINE, 
ZUR Ely RZEICREH. DIESE TASTE 
HAT & SEREN TASTEH AUCH EINE 
FORTS®§ NKTION, DIE BEL LAENGEREM 
DRUECKS - UND BEIM LOSLASSEN DER 


TASTE WIEDER AUSGESCHALTET WIRD, 
NICHT VERWENDEH. 


DIE RETURN-TASTE HAT NUR UNTER FOLGENDEN 
BEDIHCUNGEH DIE FUNKTION EINER SEnUE TASTE 
€ ZUM RECHNER >: 


o DAS TERMINAL IST NICHT IN EINEM 
MEHRTERMIHNALBETRIES (MTS) ANGESCHLOS- 
SEN 


o SIE ARBEITEH Z.ZT. NICHT IN BILDSCHIRN- 
MASKEH SONDERH IN ABFRAGE- ODER 
DRUCKPROGRAMMEN (MEHUE, QUERY, OFF- 
LINE-DRUCK > 
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Cost of hardware is going down and cost of people is going up. 


This is not a new fact, but it is only recently that research 





have made significant break through to adjust System Implementation to 


this new reality. 7 
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I. Presenting. Customer Information Products 


As the use of computers and the range of technical expertise of 
users expands, the role of customer training and documentation is be- 
coming a more vital part of computer system support. In turn, computer 
course developers and technical writers must establish direct contact 
with customers to ascertain technical and functional needs, likes and 
dislikes. This presentation should serve three purposes: 1) define 
HP's perspective on training and documentation: 2) inform our user 
base of our plans in this field: 3) solicit input from our users. 

The intention of this meeting is to inform and to be informed, that 
is, to open a direct communication link between the factory and the 
user. 

The Customer Information Products staff of Information Networks 
Division provides training and documentation for two families of HP3000 
software products: Productivity Products and Office Products. Produc- 


tivity Products include all data management tools, such as IMAGE/3000, 


VPLUS/3000, QUERY/3000, and KSAM/3000. Also included are language compilers. 


Office Products include graphics packages, text editing/word processing, 


and office printing systems. 


For all products serviced by the Customer Information Products group, 
there is an underlying philosophy of training. That is, we consider 
ourselves successful when we make customers successful in using the 
HP3000. We have found two basic ingredients necessary to do this: 1) 
carefully analyze customer needs: and 2) research what type of users 


will use each particular product. 
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Il. Analysis of Customer Needs 

The focal point of customer training is the user. In analyzing 
customer needs and user types, we are attempting to produce training 
and documentation materials which are totally user-oriented. The new 
materials we are developing attempt to present only relevant information 
to each user, in a manner best suited to that user type. We no longer 
try to present all information to all users, presented in the same 
fashion. In most cases this has become an impractical method of train- 
ing. 

In our analysis of customer needs we take many issues into 
consideration. Among these are: quick start-up, task-oriented training, 
cost-effective training, accurate and detailed product description, 
readily available training, increased system use, and increased produc- 
tivity. We are particularly aware of the need for customers to use a 
product efficiently soon after purchase. By developing training which 
is task-oriented (in other words, "how to. . .", rather than a strict 
reference type of presentation), we are able to reach many more users 
and have users avoid much frustration. 

The issue of cost-effective training can be presented from several 
points of view. Training which is streamlined to the needs of each 
user demands less time. Also, many of the training classes we are now 
developing are self-paced. This means there is no travel expense involved, 
and the user needn't be away from the office for extended periods. This 
also makes training available to many users who would not have been sent 


to a class. 
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II. Analysis of Customer Needs (continued) 

Because it is a necessity for our training and documentation to 
be accurate and detailed, we are implementing a formal evaluation 
procedure as part of our course development cycle. The evaluation 
plan will be discussed later in this paper. 

By making training accurate, specific to the user, readily 
available, and cost-effective, we will assist customers in increasing 


use of their systems and consequently increasing productivity. 
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III. Analysis of User Types 


In analyzing user types, we address two questions: 1) who 
are the users: and 2) how will they use the product? 

The first question (who are the users?) must be viewed from 
a historical perspective. Traditionally, most computer users were 
trained and experienced computer professionals. Until recently, most 
users were programmers. Today's HP3000 users include: experienced 
and inexperienced programmers, system administrators, data base 
administrators, data entry clerks, graphic designers, secretaries, 
office principals, and clerk/typists. Each of these user types has 
a different level of computer technical background and requires ap- 
propriate training. 

The second question (how will they use the product?) can best 
be addressed with sample questions we ask in developing materials. 
Specifically, we try to ascertain what the tasks of each user will be. 
For example, will a programmer be responsible only for using a subsystem, 
or will he be responsible for optimizing its use? Also, is this the 
only training the user will receive? Will he have assistance in using 
the product, or should this training make him self sufficient with the 
product? Is this product similar to other products this user might be 
familiar with? Are there other subsystems which should be mentioned 
in the training, because of products likely to be used together? Although 
specific questions about each user's tasks vary from product to product, 


the basic questions, such as those listed above, remain the same. 
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IV. Instructional Modes 


After considering customer needs and user types, we are able 
to decide on an instructional mode. That is, what type of training 
and documentation should we supply? Once agin it is necessary to 
take a historical perspective. When the majority of users consisted 
of experienced programmers, classroom training and reference docu- 
mentation served the purpose best. Reference manuals usually provide 
the necessary information for computer professionals to begin using 
a new product and supply more detailed information as they proceed. 
Classroom training provides users with technical information about 
the product, as well as application information for individual users. 
A well-versed instructor can usually supply necessary technical in- 
formation for spcific applications. 

Now, as the use of computers increases, we are seeing many 
different types of users, more and more of whom are non-computer 
technical. These users usually require more training than the users 
of the past, and a different type of training is required. In most 
cases, a tutorial approach to new materials better serves the needs 
of these users than does reference documentation. Also, most users 
prefer to learn on their own, at their own pace, with new materials 
presented incrementally. Thus, the current emphasis is on developing 
more tutorial documentation and interactive self-paced instruction 


materials. 
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IV. Instructional Modes (continued) 


Since some users have expressed interest in having contact 
with an instructor although they learn best at their own pace, we 
also plan to experiment with monitored self-paced instruction. With 
this type of instruction, students can work and learn at their own 
pace, but at an HP training center and with an experienced HP instructor 


present. The instructor will introduce the product, guide students 


through the self-paced course, and answer application specific questions. 


But what exactly is interactive self-paced instruction? Inter- 

active refers to using the HP3000 to learn about the HP3000. That 

is, all interactive instruction involves direct hands-on use of the 
system in the learning stages. The system is not only the object of 

the instruction, it is also the means. Self-paced refers to a method 

of allowing the user to learn at his own pace. The user can determine 
when he will take modules of a course, how long he will spend on each 
module, and whether or not he should repeat modules before going on 


to subsequent lessons. 
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V. Media 


The next question is: What constitutes interactive self-paced 
training? Depending on the needs and users, we pick a mixture of 
available media. Media we are currently using or exploring are: 
workbooks, audio cassettes, video tape/disc, on-line HELP facilities, 
and total on-line training. Even media such as workbooks and audio 
cassettes are part of interactive training, since we always couple 
them with use of the system. For example, a student will use a work- 
book or audio cassette while sitting in front of his/her terminal and 
will actually use the system while reading or listening. Explicit 
step-by-step instructions walk the user through the procedure of using 
the particular subsystem. 

Examples of interactive self-paced instruction with workbooks 
are: A Guided Tour of the HP3000 and Using DSG/3000. A self-paced 
course using audio cassettes is Using COBOL II. Video disc and total 
on-line training are currently being explored. One module of on-line 
training is already available as part of the System Manager classroom 
course. We are also currently working closely with the IND lab in 
designing the on-line HELP facility which accompanies many of our 


products. 
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VI. Measuring Effectiveness 


In evaluating our courses, we focus on the user once again. 
There are two methods we employ to gather input from our customer 
base. The first is by meeting formally or informally to exchange 
general information and opinions. This is what we are attempting 
to do today. The second method is by including direct interface with 
customers in the course development cycle. 

The major steps in the course development cycle are outlined 
in a flowchart on slide VI.3. Notice that we include three stages of 
materials evaluation once development has been completed: 1) materials 
are tested for technical accuracy and functionality at internal HP 
Sites: 2) materials are tested for technical accuracy and functionality 
with customers: and 3) we check known support problems to gather in- 
formation for revising materials and for planning future training. The 
boxes with shading on this flowchart represent the stages of course 
development during which customers are involved. Notice that we work 
with customers in the investigation stages, as weli as in the test 
and follow-up stages. We are making an effort to work directly with 


customers as much as possible. 
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VII. Training Plan 


Finally, it is time to introduce our entire training plan. 
The best way to do this is to present the courses available according 


to user type. For the sake of simplicity we have chosen to outline 





our courses here around five different types of users. Naturally 


these courses can be useful to other than the user types presented 


here. 
At present there are two courses for the end user, that is, the 


non-computer technical user. These are: A Guided Tour to the HP3000, 


which introduces the novice user to the major subsystems of the HP3000, 


and Using DSG/3000, which provides the non-programmer instruction in 


SLONGOYd 391330 
O0OSdH YO 


using the interactive interface of Decision Support Graphics/3000. 


QNV 
SLONGOUd ALIATLINGOUa 


For the system administrator there are currently two classroom courses: 


System Operator and System Manager. For the data base administrator 


SNINIVYL YAWOLSND NI SNCILOSYIC MIN 


there is currently one classroom course: IMAGE/3000. The application 





programmer has several courses available. Among them are: the self- 


paced course for COBOL II, and the classroom courses: Programmer's 
Introduction, IMAGE/3000, VPLUS/3000, DSG/3000 Programmatic Use, 2680 
Laser Printing System. The programmer analyst currently has one 
classroom course available: Application Design. 

At this point we would like to get your input on existing 


customer courses and what you would like to see in the future. 
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WHO ARE THE USERS? 
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HOW WILL USERS USE THE PRODUCTS? 


O WILL PROGRAMME®S BE RESPONSIBLE FOR OPTIMIZING SYSTEM USE AS 
WELL AS USING THE SYSTEM? 


O DOES THIS PRODUCT REPLACE A PRODUCT THE PROGRAMMER ALREADY 
KNOWS? 


O HOW DOES THIS PRODUCT RELATE TO OTHER PRODUCTS? 
O IS THIS TRAINING STAND-ALONE? 


O WILL THE DATA BASE ADMINSTRATOR DESIGN NEW DATA BASES, OR SIMPLY 
MAINTAIN EXISTING ONES? 


O WILL THE OFFICE PRINCIPAL NEED ACCESS TO DATA BASES? 


O WILL THE DATA ENTRY CLERK NEED TO USE PROGRAMS CR UTILITIES, OR 
JUST ENTER DATA? 
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A presentation of IPB, system 
for Interactive Planning and 
Budgeting by NU-DATA Aps. 


Abstract: 


IPB is an interactive system developed for financial planning and 
budgeting purposes with particular emphasis on the simulation side. 


The system has its own “model language” which makes it flexible and 
easy to use - also for persons without any kind of EDP experience. 
This enables the user to investigate the impact of uncertain future 
conditions and improves his understanding of the consequences of 
alternative actions. 


The IPB system is an efficient tool for the manager who knows the 
problem of not being able to achieve information about the effects 
on earnings and cash-flow of some specific changes of policy, ina 
sufficiently quick and accurate manner. 


Any accountant or financial manager who knows the problem of being 
stuck in daily routines, unable to deliver the anyalyses that manage- 
ment justly wants but seldom gets, can also profit from the IPB 
system. 
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IPB, system for Interactive Planning and Budgeting 


The structure of all planning, budgeting and calculation can 


in principle be described as: 


DATA MODEL 






RESULT 






BEPARTRERT BULGET - 
DEPARTMENT: XE 


1981 








QUARTER 











TURNOVER PROD. XXX 593250 761256 761750 676000 3011730 
- UMIT COSTS ...... 326299 416688 416688 492808 4 §©61658465 











CONTRIBUTION 1.2.06 266962 342562 342362 403199 «= 1333286 
waGclS, FOREMAN .... 30600 30600 30600 30600 122400 
ELECTRICITY ......-- : 12960 13700 13700 32400 
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DEFT, COMTRERCTION 223862 299462 298262 358879 «61186486 











ELLGET COMEITIONS: 
t 


Bresgreaasreecszesa 


SALE Th UNITS (IXK) 1130 1459 1450 1400 
FRICE FR UNIT (XxX) $25 323 525 340 
UGGES, FORERAW .... 304600 3c6co 30600 36600 










ELECTAICITV ....ceee 
COATAIEUTION FATIO 


When combining DATA with certain arithmetic rules (a MODEL) a 
RESULT is produced. If the RESULT is combined wilh a REPORT 


layout the finished text will be written out. 


FIRST SECOND THIRD FOURTH YEAR RATIO 
QUARTER .GUARTER QUARTER 19810 2Z/SALES 


eet www ewe twee ee eee eco es mews ee were Stet ee twee mem em ORE TEN 
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IPB is made to handle exactly this structure, and the calculation 


and the writing out of a budget is very simple: 


KEALY FOR COMMAND 
1.00 KUILD RESUL FROM MODEL AND DATA 


READY FOR COMKANE 
1.00 WRITE RESUL AFTER FORM 





Thus the computer takes care of the calculation/typing work 
and the decision makers can concentrate on alternatives. The 
consequences of alternatives can be illustrated like this: 


READY FOR CONHANE 
1.00 ALTERNATIVE TERMINAL 


1.00 TATA! DATA2 TATA3 
1.00 3,07 
1.00 INFLATION 0.5 





An inflation rate of 0.5 per cent per periode will be added to 
the information in the three sets of data in lines 3 and 7. 


If DATA1, 2 and 3 contain information about three departments 
three department budgets can be made using the same calculation 


rules on all three sets of data. 


REALY FOR COMMAND 
1.00 BUILD RUDG! FRON MODEL AND DATAS 


1.00 BUILD BUIG2 FROM MODEL AND LATA2 
1.00 BUILD BUDG3 FROM NODEL ANI LATAS 





BaD 


The department budgets can be added up to a total budget: 


READY FOR COMMANT! 


1.00 ABD BUG BUNG2 BUIG3 TO TOTAL 





The TOTAL result can now be written out according to the same 
report layout as the department budgets: 


REALY FOR CONMANT! 


1.00 WRITE TOTAL AFTER FORN 





if several alternatives are made in relation to the base buduet 
it is only the changes which will be of interest. If the new 
budget is deducted from the old one these changes will be in 


focus: 


REALLY FOR COMMAND 


1.00 SUBTRACT OLE TOTAL 10 CHANG 





when the budget is to be written out the cozmmand JUMP can be 
used. This entails that only the lines whose value differs 
from 0 (zero) are written out. The text will have the usual 
layout, but only factors which have been changed compared with 


the original ones will be included. 


READY FOR COMKANT! 





1.00 WRITE CHANG AFTER FORN JUNF 
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IPB has about 60 commands and instructions of which 7 are used 
in the above examples. These commands/instructions make it very 
easy for people without EDP experience to make their own models 
and reports, and also registration and processing of data are 
facilitated. 


In the following we will give a brief description of the various 
commands and instructions. 
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characteristics 


Summary of commands and instructions and their most important 


a eS ED oe 


ADD file namel, ..... , file name n TO file name. 

Adds two or more data files line by line and column by column, 
TERMINAL 

ALTERNATIVE REFERENCE file name 
These commands are used to analyse ‘what if' situations. New aiter- 
natives can often be analysed by modifying existing data files 
(e.g. insertion of new figures, adding a constant value to existing 
values, change of percentage, or making an alternative inflation). 
By using the command ALTERNATIVE such modifications of existing data 
can be made in three different wayS:- 


- line by line 
-~ in a sequence of lines 


- in lines and files referenced in a file (if the command is 
REFERENCE). 


AUTO file name 
Executes a sequence of commands and instructions stored on the 


strategy file in question. 


BUILD file name FROM file name (AND file name) 
This command results in accomplishing an arithmetic operation 
defined in a model file. The result of the calculations will be 
stored on an existing data file or on a new data file. If the 
calculations require input the command (AND file name) specifies 


where the input can be accessed. 


COPY file name TO file name 
Copies files. Especially useful in connection with alternative 


calculations (ALTERNATIVE) if a copy of the original data is 


required. 


DATA file name 
Entry of data. The data entered will be kept on a data file of the 
specified name. 


DIVIDE file name 1, ..... >» file name n TO file name 
This command allows the user to divide data files quantity by 
quantity. 


GET file name 
Creates a new file by joining lines from one or more existing 
files. 


MATRIX file name * file name TO file name 
The command executes different kinds of matrix operations. 


MERGE file name 1, (file name 2) TO file name 
This command enables the user to create new data files from 
existing data files in any possible way. 


MODEL file name 
Definition of arithmetic operations. These will be kept in a file 
under the specified name. 


MULTIPLY file name 1, ..... » file name n TO file name 
The use of this command multiplies two or more data files 
quantity by quantity. 


PURGE file name 
Deletes the file. 


REFERENCE file name 
In connection with alternative calculations it may often be use- 
ful to alter several lines in different data files by one 
operation. For instance all lines c “aining information of a 
currency will be changed by a percentage as a result of a new 
rate of exchange; or all lines containing information of the 
price of petrol per gallon will be increased by the amount XX, 
which is a new tax. The REFERENCE command allows the user to 
combine any data line in any data file by a reference. 
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REPORT file name 
Definition of output structure, i.e. which lines and columns from 
which file are to be written and which layout is to be used. 


SCHEME file name 
This command is used to design and print schemes for data. 


STOP 
Terminates the program. 


STRATEGY file name 
Allows the user to create a chain of commands and instructions. The 
sequence of commands and instructions will be kept in a strategy 
file after which it is possible to execute the sequence by one command 
only. This command can be used for example when the company budget 
is to be gathered from several department budgets, etc. 


SUBTRACT file name 1, ..... >» file name n TO file name 
Subtracts data files quantity by quantity. 


UPDATE file name 
Any column and line in the specified data file can be updated 
(changed) by the use of UPDATE. 


WRITE file name AFTER file name 


This command prints a data file according to the structure specified 
under REPORT. 
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INSTRUCTIONS 


COLUMNS 
The system operates with columns 1 - 30. If the user wants to 
change the number of columns or if certain columns should be 
reserved for later use the instruction COLUMNS should be applied. 


CONSTANT 
Replaces specified data by a constant. 


DATE 
Writes today's date. 


DECIMAL 
Controls the number of decimals in the output. 


DIVISOR 
This instruction is used to reduce the values in one or more 


lines in a data file by a divisor. 


FACTOR 
This instruction is used to increase the values of one or more 


lines in a data file by a factor. 


HEADING 
Prints a heading on all pages in a report. 


IF 

Used as a conditional expression under GET and MERGE. 
IF - - - ELSE 

Logical espression which can be used in the calculations. 
INFLATION 


Adds inflation to defined data lines (a percentage calculation). 


F5 1) 


INTERVAL 
All lines in data files, model files, report files, reference files 
as well as in strategy files are numbered. The system generates 
line numbers automatically with increments of 1. This can, however, 
be changed arbitrarily by the instruction INTERVAL. 


LINE 
Prints a line of specified characters in the report. 


LIST 
Gives a listing of the file which is in use. 


MINUS 
Subtracts a constant from data specified by the user. 


MOVE 
Moves one or more columns in a data file. 


NEWCOL 
Changes the number of active columns in data and model files. 


PAGE 
Changes to a new report page. 


PERCENTAGE 
Changes specified data by X per cent. 


PLACE 
Is used to copy sequences of lines as well as single lines from a 


data file to a model file. 


PLUS 
Adds a constant to data specified by the user. 


READY 


Terminates the use of any command; the system is then ready for a 


new command. 
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RECIPROCAL 


Gives a reciprocal change on one or more lines in a 
data file 


SEQUENCE 
Controls the sequence in which the columns are to be printed in 
the report. 


SUBHEADING 
Prints a column heading. 


TEXT 
Inserts a text line in the report. 


UNIT , 
Defines the unit in which the output should be printed. E.g. the 


output is wanted in thousands (UNIT 1000), hundredths (UNIT 0,01) etc. 


Cxx 
Defines the column number. Arithmetic operations can be executed on 
lines as well as on columns. 
Dxxx.xx 
Definition of data lines (up to 99999 in one data file). 
DIMXxxx. XX 
Modifications of data line xxx.xx 
[LLXXX.XX 
Definition of model lines (used when arithmetic operations are 
executed on columns). 
MxXxXX.XX 


Modifications of line xxx.xx 


PXXX.XX - Pyyy.yy 
Purges ]in€S xxx.xx - yyy.yy 
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Commands 


Instructions 


- 


COLUMNS 
CONSTANT 
DATE 
DECIMAL 
DIVISOR 
FACTOR 
HEADING 


IF 
INFLATION 
INTERVAL 
LINE 

LIST 

MINUS 

MOVE 
NEWCOL 
PAGE 
PERCENTAGE 
PLACE 

PLUS 

READY 
RECIPROCAL 
SEQUENCE 
SUBHEADING 
TEXT 

UNIT 


Cxx 

DXXX.XX 
DMXxx.XxX 
LXXX.XX 
MxxXX.XX 
PXXX.XX 
*(asterisk) 
; (semicolon) 
Data line 
Model line 
Column calculation 


ADD 


ALTERNATIVE 


Survey of commands and instructions 


jp “MULTIPLY 
. PURGE 


| REFERENCE 
| REPORT. 
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"SOFTWARE TECHNOLOGY 


A FUTURE REQUIREMENT OR CURRENT NECESSITY?” 


De. Harry BLAsK 


Ladies and Gentlemen, 


1. Introduction 


Every time a new technical achievement is made there are a 
few resourceful minds who are quick to make use of it) to the 
disadvantage and detriment of their fellowmen. ‘So the 
development and propagation of information technology has 
"blessed" mankind with so-called computer crime. | would 
Like to cite one of the cases reported to date which | think 
is of particular interest to the subject of my paper: 

A few years ago, an audit. was announced unexpectedly in oan 
English bank. The result. was that some employees of the data 
processing division disappeared overnight (and probably ett 
the country). This practically confirmed the suspicion that 
irregularities had occured. The software was then cxamined 
with special care; but in spite of an intensive search. the 
manipulat.ions which had most probably been made couldd not) be 
discovered. 

This example throws speeial Light on Che present vf bware 
situation: Fven spectalists Vail to detect crtisting crroes 
or manipulations. 1 would Tike to examine this situation 
further in a somewhat. generalized manner betore Po ooeventual ts 


embark upon the actual subject namely software technology. 
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2. Situation and impact of information technology 
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[In modern industrial societies, the generation, processing 
and transfer of information are playing an increasingly 
important role. Together with microelectronics, data 


processing and technical communication, information 
technology represents a key technology which none of the 
major industrialized nations can afford to neglect. 
Consider. for instance, the increasing integration, and the 
further decline in prices. of electronic components: here, 
future development will lead to fundamental changes for 
manufacturers and users of information technology as well as 
for private users. Since we are still at the beginning of 
this process. we can by no means predict all the 
consequences which will be brought about by information 
technology. Some effects. however, are already cmerging 


today with a sometimes depressing clarity: 


- The institutions using information technology and, in the 
final analysis, society as a whole is becoming more and 
more dependent. on this technology. Lmportant sectors of 
production engineering, the control of complex technical 
plants, the administration and handling of large stocks of 
information, all these are practically no longer possible 
without data processing. It data processing ever fails, 
this may have disastrous consequences, including even the 
destruction of companics. One of the main clements of the 
vulnerability of those who rely largely on information 
technology is the increasing complexity of echnical 
systems and their applications. They make use of 

electronic information processing because, above all. this 

aflows numerous Links and interconnections leading to new 
information. The 


complexity make: the systems less Cransparent. less 


resulting trend towards increasing 
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controllable, and capable of being mastered by only a few 
specialists as was illustrated by the example I quoted at 


the beginning. 


~ Information technology also penetrates increasingly into 
sensitive areas. It controls railway and tram signalling 
installations; air traffic control is more and more 
computer-assisted. Presumable nuclear power stations, too, 
will soon be monitored and controled by computers; this, 
however, is not yet permitted in the Federal Republic of 
Germany. Errors or failures occuring in these areas would 
result in serious accidents involving loss of life. We 
have still far to go before finding a solution to the 
problem of ensuring the reliability of information 


systems. 


If we now consider information technology from the hardware 
and software aspects, we will find that the software has 
nothing comparable to set against the technical progress of 
hardware. This is probably due to the fact that hardware is 
the result of engineering to a much greater extent than 
software and that engineering uses sophisticated working 
techniques and theoretical elements with a long tradition. 
They were already known and practised long before data 
processing was developed. Programming, on the other hand, is 
relatively new. It takes place at the boundary between 
technology, organization and the humanities and to this day 
is considered an "art" and not a science. When a system is 
implemented the cost share of software todey is already in 


the region of 80% and shows a tendency to increase. 
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3. The software crisis 


Let us first of all consider the manifestations of the so- 
called software crisis. When comparing the’ software 
development of 20 years ago of that of today we find that 
little has changed. The scene is still dominated by the 
"free lance artist" who produces software without observing 
too many rules, giving free rein to his intuition. For him, 


it is not important that 


~ software be structured in a transparent and intelligible 
way so that later on it can be understood and, if 
necessary, modified or supplemented also by’ the other 


users, 


- adequate documentation be provided for programmes; this 
applies even more to considerations of, and decisions on, 
design, which today are put down in writing in very few 


cases only, 


- an extensive phase of problem analysis and definition 


precede the design and implementation phase, 


- programme protability is achieved. 


As a result, software is prone to many errors; in the case 
of major operating systems, for example, between 5000 and 
10000 errors per year are reported to the manufacturer. It 
is often found that software is no longer usable soon after 
its developer has left the company or if development 


capacity is no longer accessible for other reasons. 
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Other symptoms of the crisis are: 


- Users and developers have difficulty in communicating with 
each other. Having different engineering backgrounds, they 
do not speak the same language. Communication is further 
complicated by the fact that the colloquial language we 


normally use is informal and imprecise. 


- The means of expression and description available for 
software development are inadequate. This applies in 
particular to graphical means. The large variety of 

languages available 


programming complicates 


standardization. 


- Progress and productivity in software production are 
particularly difficult to control. While between 1958 and 
1978 the processing productivity of computers increased by 
a factor of 1000, the productivity of programmers 
increased only by a factor of 2! Projects are managed and 
organized in a shirt-sleeve manner and consequently yield 
unsatisfactory results. A study carried out by the 
University of Karlsruhe involving 100 automation projects 
showed that, on average, software had additional time 
requirement of about 50%, while the costs were about 75% 


higher than estimated. 


In addition to these qualitive characteristics of the 
"software crisis", there are some important economic 


aspects: 


a) In the Federal Republic of Germany alone, about DM 10 
thousand million are spent annually on software. About 
80% of the costs of a data processing application are 
accounted for by software. On the one hand, this is due 


to the fact that software is designed to fulfil 
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increasingly complex tasks - thus becoming increasingly 
complex and expensive itself -, on the other hand, 
microelectronics brings out price cuts’ for hardware, 


while this can hardly be said about the soft- ware side. 


b) Competition between data processing suppliers has been 


shifting to the software sector. This applies without’ 


reservation to operating systems, which determine 


computer characteristics much more then hardware does. If 


you just remember how many computers - especially smaller 
ones - use the standard components’ from Intel, Texas 
Instruments, Motorola and Fairchild, you will recognize 


that the net value added to a product and its identity 
and hence its competitve ability come from the software, 


including application software. 


c) Available data processing solutions are _  ihadequately 
portable or not portable at all. The same _ problem 
definitions are therefore handled again and again - a 


practice which constitutes an enormous economic waste. 


This is why we have to look for new approaches in order to 


reduce the cost of software development and maintenance. 


Just as we use high-precision tools in = production 
engineering, we will have to use the computer itself for 
software production. Neither our own capabilities nor our 


own ability to analyse and integrate are sufficiently 


powerful to cope with the software crisis. 
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4. The software technology scene 


Approaches to software production technology have developed 
since the late 60's and appear promising: at the present 


time, however, the term "technology" is rather flattering. 


Today, software development and maintenance are generally 


based on the following phascs: 


- requirement analysis and speciticat ton 
- rough design 

- final design 

- coding and implementation 


- maintenance. 


To include testing in this list as a phase of its own would, 
I think, not. be correct, since testing activities occur in 
all the phases cited above. For all phases, there are iso- 
lated solutions with quite different capabilities. Computer- 
aided tools and methods for the requirement (analysis and 
specification) phase have so tar’ been the least developed 
elements. One of the main reasons’ for this is probably the 
fact that there is a contradiction between the necessarily 
application-oriented character of this activity and the need 
for highly flexible tools for varying applications. For the 
rough and final design phases, the situation tis better: 
several methods (e.g. the Jackson method, structured 
programming) are at least known to users by name, although 
they are actually used only by a_ few advanced software 
developers. In the coding phase, which is the traditional 
field of activity of programmers, methods and tools of 
software technology are more wide-spread, of course, whereas 
the maintenance phase is still characterized by a very small 


inventory of methods and tools. 
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The methods, techniques and tools used are often quite 
sophisticated and hence can be applied only by experts. In 
addition, the value of software technology is frequently not 
easy to understand. It is absolutely impossible for the 
normal user to estimate the value’ of such technological 
tools. AS a consequence, the barriers preventing their 
introduction are tremendous: there is a great reluctance te 
introduce such tools on the part. of mangement boards, who 
hesitate to invest the large funds required for the 
necessary training effort and for investments, as well as 
on the part of software developers, who are expected to five 
up their old familiar working methods and to aquaint 
themselves with new sophisticated techniques. In view of 
this situation it is no wonder that tools of sottware 
technology are not yet widely used either in the  lederal 


Republic of Germany or, probaly, in other countries. 
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§. Measures initiated by the BMFT to support 


software technology 


meee ee ewe es we we we ee i i ee we ee we eS 


In order to prepare the ground for support measures, the 
Federal Ministry for Research and Technology entrusted the 
Society for Mathematics and Data Processing (GMD) with the 
undertaking of a study to analyse measures for’ the 
improvement of software production and to identify research 
areas which, in the medium term, are, or will be, of 
importance for users and software producers. The study also 
included a detailed analysis of the market of software 
suppliers in the Federal Republic of Germany. Let me cite a 


few results of the study: 


There are about 3.000 suppliers of software in the Federal 
Republic. About 85% of them have a capital of less than DM 
250.000, which means that most of them are not able to 
raise enough funds of investment in tools of software 
technology. But also the more powerful suppliers who would 
be able to invest have not, as a rule, reached a 
satisfactory level of know-how concerning software 
technology. Owing to this situation, the software industry 
will, in the medium term, not be able to make use of the 
existing growth opportunities, since its technological 


know-how and also its economic potential are limited. 


A country like the Federal Republic which - because of its 
dependence on imports - must be able to offer 
technologically advanced products cannot affort to neglect 
important key industries. The situation I have just 
described almost inevitably calls for the government to 


initiate supporting measures. 
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Under 3 successive data processing programmes from 1967 to 
1979, the Federal Government gave support to research and 
development activities for hardware and software. A total of 
about 3.5 thousand million was provided to support research 
and development in this field. The first programme focused 
on hardware, the second and third on software, with an 
increasing emphasis on small computers. Applications of data 
processing in many different areas were supported (e.g. in 
administration, medicine, process’ control, computer-aided 
design or education). By promoting the field of data 
processing during the years up to 1979/1980, many of the 
objectives of the data processing programmes, which were 
designed as a pump-priming measure, have been achieved. As a 
consequence, the financing in particular of future products 


and standard applications will now be left to industry. 


Present support measures concentrate on existing deficiency 
areas in information technology. To give you an idea of 
these measures, let me cite - apart from software technology 
- a few other important areas in which support is given 


predominantly to basic research work and systems know-how: 


- data security 

- information technology for office and administration tasks 
- very-large-scale integration of electronic systems 

- fundamental principles of systems engineering 

- pattern recognition 


- communications technology. 


I do not want to go into greater detail. For those who are 
interested, let me point out that the support measures 
proposed are always announced in the Bundesanzeiger, the 


official organ of the Federal Government. 
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From the above remarks on the software crisis it’ is 
immediately obvious that much remains to be done in the 
field of software technology. This need is certainly not 
controversial. It is also, I think generally accepted that 
the quality of software can be improved, above all, if a 
systematic approach is developed and introduced for the 
problem definition and the design phases. But opinions 
differ when it comes to deciding which methods are the most 
efficient, since this quantitative efficiency is analysed or 
proved only very rarely; which means often beliefs are 


stated in the absence of evidence. 


It would be just fine if the whole software life cycle could 
be covered by a few methods. But this is wishful thinking 
and hence unrealistic. One of the conclusions of the 
abovementioned study by the GMD is that. the development of 
methods cannot be separated from the individual products to 


be developed. 


The means of expression for design and testing certainly are 
- other methods may be - dependent on the kind of product to 
be developed (e.g. micro-systems, compilers). Nevertheless, 
there are certainly also a number of methods which Lend 
themselves to general use. The variety of techniques, 
methods and tools required is and will be large - at least 
judging by the present state of the art and by present 
know-how. A policy aiming at the advancement of software 
technology and its use in the Federal Republic of Germany 
has to take this fact into account and consequently has to 
support a relatively large number’ of means of software 
technology before strategies can emerge which it would be 
promising to pursue with emphasis and in cooperation between 
several parties. We are focusing our support measures on 
areas where we belicve the standard of know-how is 


particularly low. These areas are: 
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Methodology 


Existing methods and tools are at present often used for 
only one or several software development phases. As 
development. work proceeds to the next phase, extensive 
modification operations and manual adaption work are 
usually necessary, which would not. be required if we had a 
coordinated and integrated system of methods. Whether 
eventually a system can indeed be developed which would be 
able to support the whole software ite cycle from the 
requirement analysis to the maintenance’ phase without 
intermediate manual work is, I think, open to doubt. It is 
clear, however, that methodology is at present an area 
with quite considerable deficiencies. And since’ even 
relatively little progress can be expected to yield 
significant growth in productivity and improvement of 
quality, about 60 per cent of the funds available for 


software technology are earmarked for this area. 
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Individual methods in deficiency areas 
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Although some methods do exist, they are not all 
particu- larly satisfactory. In this area, we give 
specific support to graphical methods, because they seem 
to us especially promising for an engineering approach. 
The Petri networks may play an important role one dav in 


this connection. 


- Quality assurance 


in particular testing. In addition to testing the code. 
testing (also by machines) during the first phases of 
the software life cycle will be of increasing 
importance, in particular because errors in the 
description of re- quirements and in software design are 
particalarly expen- sive errors, since they are usually 
detected at a late stage and following extensive 


searches. 


It is hoped that. two projects which we support. and which 
are dedicated _ to programme verification, i.e. proving 
that the code contains no errors, will be successful. If 
a real breakthrough is achieved here, we shall feel far 
less concern than before at the thought of using 


software also in sensitive areas. 
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- Maintenance 
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50% to 80% of the cost. of a software product during the 
entire period of its use are caused by maintenance. 
Improved maintenance will be achieved automatically when 
better methods are used for the initial phase of the 
software development. But apart from that, improved 
methods of maintenance must also’ be developed. We are 
giving special support to activities for the development 


of remote diagnosis and maintenance. 


Evaluation of methods 


As 1 said before, this is an issue of special interest to 
the user. The trouble is that the situation with regard to 
methods evaluation is particularly gloomy. There = are 
practically no measuring methods and techniques which 
could yield quantifiable and meaningful evaluative 
results. The projects we are supporting do not at present 


include any such activities. 


One of the requirements we have fixed for all the projects 
we promote is that. the processes and methods can be used 
with computer support. If they cannot. be used in this way we 
are afraid they will mostly not be a long-term success in 


practice. 


A second reason for this requirement is the fact that a 
method is not mature, logical and consistent until it can be 
programmed. The work we support is intended to achieve 
progress in software technology. The development results 
must be largely portable so as to facilitate more general 
application. Developments which are of value first and 
foremost. to one interested party only, will not receive 
support. In the case of private enterprises it 1s out 


general policy to bear only 50% of the project costs. 
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6. 


EC. 


In 


Supportive ‘measures by the Furopean Communities 


Shall now say a few words about support measures by the 


1979, The Council of the European Communities adapted a 


programme of supportive measures for the field of data 


processing covering the period from t979 to LOSS. Over these 


four  vears., Che programme will provide 25 million turopean 


Vecounting Units. The  progmiumme is subdivided into two 


parts: 


a) 


b) 


General action 


Dealing with standardization. public procurement. 
cooperation between research centers and organizations 
which advance the use of data processing. studies on 
employment issues; data security and data protection as 


well as the legal protection of computer programmes. 


sottware and applicat tons 


In the field of general software, the EC Commission gives 


support to projects aiming at: 


- the establishment and dissemination of standards 
- improved portability 
- improved conversion condit ions 


- improved efficiency of data processing systems. 
The supportive measures in the field of applications are 


not Limited to certain fields, but’ they have to comply 


with specific criteria, which | do not, however, wish to 
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cnumerate here. The programme's terms of reference are so 
general that a relatively wide range of tasks can be 
included. More specifically, software technology projects 
are also eligible for promotion. In order not to raise 
false hopes, let me point out to you that all projects to 
be supported by the EC must comply with the requirements 
of advancing cooperation within the EC, which means that 
they must be carried out jointly by institutions in at 
least 2 EC countries. The measures supported by the 
Commission are aanounced annually in the official Gazette 


of the European Communities. 


In addition to the steps taken by the EC Commission, 
other European countries, besides the Federal Republic of 
Germany, also have initiated action for the support of 
information technology. These measures differ very much 
from cach other so that it would take too much time to go 
into further detail. Generally speaking, it can be said, 
J think, that small EC countries (e.g. Denmark, the 
Netherlands, Belgium) do not give financial support to 
industrial information technology activities, whereas 
larger countries like the United Kingdom and France 
provide quite considerable funds for this purpose. The 
resposability for national support) measures is assigned 
t.o different government. departments in different 
countries, often to the department of industry, research 


or education. 
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7. Considerations on a future coordinated system technology 


Before - in conclusion - trying to answer the question asked 
in the title of my paper, let me draw your attention to a 
technology of which the software technology is only one 
aspect. Hardware and software (by software I mean both 
operating systems and user software) were poorly coordinated 
from the first vears of the great increase of computer use. 
As hardware development raced ahead, leaving software a long 
way behind, the gap between the two grew wider and will even 
increase as new hardware architectures are developed. The 
existing programming languages and techniques would make 
only very effective use of the possibilities offered by 
hardware. Consequently, it is an increasingly urgent task to 
make hardware and software development converge into a co- 


ordinated system technology. 
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8. Conclusions 


To summarize, Let me emphasize that the software crisis must 
be overcome as soon as possible. As I said before, some DM 
10 thousand million are spent annually on software in the 
Federal Republic of Germany. Successful rationalization in 
software, production which reduces’ in particular the amount 
of maintenance required will soon result in major economies. 
If the software crisis is not overcome, the majority of 
staff engaged in software production would spend all their 
time on maintenance work and therefore be unable to tackle 
urgent) new tasks. It is frightening to think that. a very 
large portion of the qualified manpower engaged in data 
processing - which is in short’ supply anyway - is not 
available for innovation work which is urgently required by 
the economy. The need to reduce the great dependence and 
vulnerability caused by information technology by improving 
the structure and thus the managability of software is 
another aspect which is’ of interest to the society as a 


whole. 


The software producer is at present in a rather favourable 
situation compared with other producers. This is due on the 
one hand, to the extremely high demand for software, which 
can hardly be met, and, on the other hand, to the fact that 
for many customers software is still a book with seven 
seals, so that they have to fully rely on the producers. I 
am sure that this situation will, however, change during the 
next few years. Users will become increasingly aware of the 
problems involved in information technology and will 
endcavour to aquire at least some basic knowledge. They will 


then look at software with a more critical eye and will - 


more often than in the past - demand better quality. 
Software producers who are not able to meet such 
requirements will not be able to hold their market position. 
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The availability of the tools of software technology will 
then be crucial prerequisite for the survival of a company. 
Since software technology cannot, however, be introduced 
overnight, but probably only in the course of several years, 
software producers would be wise to begin immediately to 
tackle this task. Difficult as this task may seem in the 
face of such a multitude of methods, it should not be 


postponed, since any delay jeopardizes future opportunities. 


Thank you for your attention. 
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ANSI COBOL 198X: The Story behind the Headlines 


Greg Gloss 
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ABSTRACT 


The ANSI (American National Standards Institute) X3J4 technical 
committee is in the final stages of its work on the next version 
of the COBOL standard. This paper will discuss some of the major 
new features which are expected to be included such as structured 
programming constructs together with those items which will no 
longer be allowed in the next standard. Some background 
explaining the reason the committee chose to make some of the 
changes will be included. In addition, the standardization 
process will be covered briefly. 


BACKGROUND 


The current version of ANSI COBOL was adopted in 1974. Since 
1977, the ANSI X3J4 committee has been working on the next 
version of the COBOL standard. Since it is not clear how 1>ng 
this process will take, I will refer to the next standard as 
COBOL ‘8x. 


OVERVIEW 
The next standard will have changes in the following categories: 


New Features 
Transitional Features 
Deleted Features 
Specification Changes 
New Reserved Words 
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A significant effort has been put into incorporating structured 
programming constructs into COBOL. In addition, other new 
facilities have been added to make programming in COBOL easier. 
Some current features have been flagged for deletion either in 
the new standard or in the subsequent standard. Those features 
which are in the new standard, but which are not expected to be 
in the subsequent standard are called transitional. There have 
also been some changes to the rules and additional reserved words 
includ d which may affect existing programs. 


STRUCTURED PROGRAMMING 


The new structured programming constructs which have been defined 
for COBOL include Scope Terminators, nested programs, PERFORM 
statement enhancements, the EVALUATE statement, and the CONTINUE 
statement. 
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Scope Terminators 


Under COBOL '74, conditional statements could not be included 
with the statement group following a conditional phrase such as 
AT END or ON SIZE ERROR. New reserved words have been added such 
that any conditional statement can be turned into an imperative 
statement and used as part of the conditional Statement group. 
For example, 


READ FILE-IN AT END 
ADD A TO B ON SIZE ERROR 
PERFORM OVERFLOW- ROUTINE 
END-ADD 
MOVE SPACES TO REC-IN. 


Under COBOL '74, it is not legal to Specify the ON SIZE ERROR 
phrase in the above example because it turns the ADD statement 
into a conditional statement and only imperative statements are 
allowed following the AT END phrase. However, with the scope 
terminator, END-ADD, the ADD statement with the SIZE ERROR option 
becomes an imperative statement and is legal in this situation. 
The MOVE statement is the second imperative statement to be 
executed if the AT END branch is taken and the period terminates 
the READ statement. If the READ itself were nested under a 
conditional such as an IF, it would be terminated by an END-READ 
instead of the period. 


Nested Programs 


The nested program facililty allows programs to be contained 
within other programs so that global data may be easily shared 
and the program structure and relationships-specified. In the 
following example, program B is contained within program A. 


IDENTIFICATION DIVISION. 
PROGRAM-ID. A. 
ENVIRONMENT DIVISION. 
DATA DIVISION. 
[Global Data Declarations] 
PROCEDURE DIVISION. 
[Program A Procedure Division Statements] 
IDENTIFICATION DIVISION. 
PROGRAM-ID.  B. 
ENVIRONMENT DIVISION. 
DATA DIVISION. 
[Local Data Declarations] 
PROCEDURE DIVISION. 
[Program B Procedure Division Statements ] 
END PROGRAM B. 
END PROGRAM A. 
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Program A may call program B; however, program B cannot call 
program A. Program B can access data in program A which is 
declared as GLOBAL unless program B contains a local data item 
of the same name. 


PERFORM Statement Enhancements 


The PERFORM statement has been enhanced to allow a list of 
imperative statements to be embedded within the statement instead 
of paragraph names and to allow the programmer to specify whether 
the UNTIL conditions are to be tested before or after the 
Specified set of statements has been executed. 


An example of an in-line PERFORM is shown below: 


PERFORM 10 TIMES 
ADD A TO B 
ADD 1 TOA 

END- PERFORM. 


The two ADD statements will be executed 10 times. 


Under COBOL '74, the UNTIL conditions are always tested before 
executing the specified Paragraphs. The new specifications will 
allow the test to be made afterwards. For example, 


PERFORM READ-LOOP 
WITH TEST AFTER 
UNTIL EOF-FLAG. 


Control will always transfer to READ-LOOP at least once. The 
test option may also be Specified with an in-line PERFORM. 


EVALUATE Statement 


The EVALUATE statement adds a multi-condition CASE construct to 
COBOL. The EVALUATE Statement causes a set of subjects to be 
evaluated and compared with a set of objects. If the comparisons 
are all true, a specified froup of statements is executed. For 
example, 


EVALUATE HOURS-WORKED EXEMPT 
WHEN 0 ANY PERFORM NO-PAY 
WHEN 1 THRU HO ANY PERFORM REG-PAY 
WHEN 41 THRU 80 "N" PERFORM OVERTIME-PAY 
WHEN 41 THRU 80 "Y" PERFORM REG- PAY 
WHEN OTHER PERFORM PAY-ERROR. 


The above example evaluates two data items, HOURS-WORKED and 
EXEMPT. If HOURS-WORKED is 0, any value for EXEMPT will 

be true and NO-PAY will be performed. If HOURS-WORKED is between 
1 and 40, REG-PAY will be performed. If HOURS-WORKED is between 
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41] and 80 and EXEMPT contains "N", OVERTIME-PAY will be 
performed. If HOURS-WORKED is between 41 and 80 and EXEMPT 
contains a "Y", REG-PAY is performed. If none of the above 
conditions are true, PAY-ERROR is executed. 


CONTINUE Statement 


The CONTINUE statement is a no operation statement which 
indicates that no executable statement is present. It may be 
used anywhere a conditional statement or an imperative statement 
may be used. For example, 
0 
IF A < B THEN 
IF A < C THEN 
CONTINUE 
ELSE 
MOVE ZERO TO A 
END-IF 
ADD B TO C. 
SUBTRACT C FROM D. 


The CONTINUE statement allows control to go to the ADD statement 
following the IF when A is less than C. If the NEXT SENTENCE 
option had been used, control would have transferred to the 
SUBTRACT statement instead. 


OTHER NEW FEATURES 


There is a long list of other new features which should make the 
job of the COBOL programmer easier. The more significant 
ones are listed here. 


Reference Modification 


Reference modification allows you to reference a portion of 
a data item by specifying a leftmost character position and a 
length. For example, 


MOVE A (3:5) TO B. 
will move the third through seventh characters of A to B. 
INITIALIZE Statement 


The INITIALIZE statement provides the ability to set selected 
types of data fields to predetermined values. Assume RECORD-1 
was described as follows: 


01 RECORD-1. 
05 EMP-NO PIC 9(6). 
05 EMP-NAME PIC X(20). 
05 EMP-PAY PIC 9(5)V99. 
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05 JOB-TITLE PIC X(20). 


The following INITIALIZE statements in the Procedure Division 
could be used to put values into the record: 


INITIALIZE RECORD-1 REPLACING NUMERIC BY ZERO. 
INITIALIZE RECORD-1 REPLACING ALPHANUMERIC BY SPACES. 


The effect would be the same as: 


MOVE ZERO TO EMP-NO EMP-PAY. 
MOVE SPACES TO EMP-NAME JOB-TITLE. 


De-editing 


Under COBOL '74, it is not legal to move from an edited field 

to a numeric or numeric edited field. The new specifications 
will allow moving from a numeric edited item to either a numeric 
or numeric edited item. The edited item which is the sending 
item will be converted to its numeric value and moved to the 
receiving field. 


REPLACE Statement 


The REPLACE statement function is similar to that of a COPY... 
REPLACING except that the REPLACE statement operates on all 
source program text, not just text in libraries. Thus, if one 
of the new reserved words is used heavily in an existing 
program, you may want to use a REPLACE statement to change it. 
For example, 


REPLACE ==TEST== BY ==TESTT== 
will replace all subsequent occurrences of TEST by TESTT in the 
source program until another REPLACE statement, a REPLACE OFF 
statement, or the end of the source program. 


Optional FILLER 


The word FILLER is now optional for data items which need not 
be named. 


Ol A. 
05 B PIC X(5). 
05 PIC X(5) VALUE "NAME:". 


INITIAL Attribute 


The INITIAL clause in the PROGRAM-ID paragraph indicates that 
every time the program is called, the internal data is 
initialized. This function is the same as the $CONTROL DYNAMIC 
option on the HP-3000. 
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PROGRAM-ID. SUB-PROG INITIAL. 
EXTERNAL Attribute 
The EXTERNAL clause specifies that a data item or file is 
available to every program in the run unit which describes the 
data item or file. 

FD FILE-1 IS EXTERNAL. 
SYMBOLIC CHARACTERS Clause 
The SYMBOLIC CHARACTERS clause in the SPECIAL-NAMES paragraph of 
the Environment Division allows the programmer to equate a name 
to a specific character. This feature can be useful for 
non-printable characters. For example, 

SYMBOLIC CHAKACTERS BELL IS 7, CARRIAGE-RETURN IS 13. 
This clause would allow a MOVE statement such as 

MOVE BELL TO A. 


ADD Statement Enhancement 


Under COBOL '74, the ADD statement allows either a TO ora 
GIVING format, but a statement of the form 


ADD A TO B GIVING C 


is not allowed. The new specifications will allow the TO 
before the last operand when the GIVING option is used. 


Alphabetic Tests 
Two new alphabetic class tests have been defined: 


1. ALPHABETIC-UPPER will be true if the data item being 
tested contains only A-Z and spaces. 


2. ALPHABETIC-LOWER will be true if the data item being 
tested contains only a-z and spaces. 


SET Statement Enhancements 
The SET statement has been enhanced to allow the setting of 
external switches either on or off and condition-names to true. 


For example, given the following declarations: 


SWO IS SWITCH-1 
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01 READ-FLAG PIC 9. 
88 EOF-FLAG VALUE 1. 


The following SET statements could be used: 


SET SWITCH-1 TO ON. 
SET EOF-FLAG TO TRUE. 


The second SET statement is equivalent to: 
MOVE 1 TO READ-FLAG. 
TRANSITIONAL CATEGORY 


There are some features of the current standard which are 
scheduled for a phased deletion. Implementations must still 
support these features in the new standard, but not in the 
subsequent standard. 


One of the most visible areas of change in the transitional 
category is in the realignment of file related clauses. The 
Environment Division is intended for machine dependent functions 
and the Data Division for machine independent functions. 
However, the placing of some clauses in the current COBOL ‘74 
standard does not conform to this concept. Therefore, certain 
clauses have been moved from the file control entry in the 
Environment Division to the file description entry in the Data 
Division and vice versa. The old locations are specified as 
transitional elements so implementations of the new standard must 
support programs which contain the clauses in either the old or 
the new locations. The following Environment Division clauses 
are included in the transitional category: 


FILE-STATUS 
RECORD KEY 
ALTERNATE RECORD KEY 
ACCESS MODE 


The following Data Divison clauses are included in the 
transitional category: 


BLOCK CONTAINS 
CODE-SET 


The Identification Division paragraphs are included in the 
transitional category in favor of the more general comment 
facility (* in column 7). Part of the reason for this change 
is the problem with the use of the word COPY in these 
paragraphs. It is not clear whether COPY in a comment entry 
is intended to be a COPY statement or is merely part of the 
conunent. 
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The INSPECT...TALLYING...REPLACING format of the INSPECT 
statement is included in the transitional category since 
the same function can be accomplished with two separate 
INSPECT statements. 


DELETED FEATURES 
The following features are not included in the next standard: 


1. The ALTER statement. 
2. The ENTER statement. 
3. The MEMORY SIZE clause. 


The ALTER statement is being deleted because it is widely 
accepted as poor programming practice which causes significant 
program maintenance problems. The ENTER statement and MEMORY 
SIZE clause are being deleted from the standard because they are 
primarily implementor defined functions which are not necessarily 
meaningful on all systems and are thus not portable. 
Implementations will still be allowed to support these 

three features as extensions to the standard. 


OTHER CHANGES 


New status code values for file errors are being defined. These 
codes will cover situations which violate the standard but for 
which no standard status code was defined. For example, trying 


to open an indexed file in a program which declares it to be 
a relative file. 


The order of the steps in a multi-conditional PERFORM. ..VARYING 
statement has been changed. Under COBOL ‘74, the statement 


PERFORM PAR-1 VARYING I FROM 1 BY 1 UNTIL I>10 
AFTER J FROM I BY 1 UNTIL J>10 


would set I to 1 and vary J from 1 to 10 and then set J tol, 
increment I to 2 and vary J until 10. The new specifications 
will increment I to 2 before setting J to I. Thus, on the second 
eycle, J will vary from 2 to 10 instead of 1 to 10 as under COBOL 
‘TH. The primary reason for this change is because this 
statement, as currently defined, has caused much confusion 
because it doesn't do what most people expect and is probably not 
used very much. Programmers who have attempted to use this 
statement to do a bubble sort have usually been surprised at the 
results. 


The new reserved word ALPHABET is required in the alphabet 
clause of the SPECIAL-NAMES paragraph. 


ALPHABET ASCII IS STANDARD-1. 


This change was required because of the desire to minimize the 
portability problems caused by implementor-defined reserved 
words. Under the COBOL '74 standard, the implementor could 
reserve the words used for switches, alphabet-names, and 
output advancing controls. The new standard will not 

allow these words to be reserved. This change however 

caused a parsing problem in the SPECIAL-NAMES paragraph 
because it would not be clear whether a clause such as 


SWO IS EBCDIC 
was specifying that EBCDIC was the mnemonic-name for switch 
SWO or whether SWO was the mnemonic-name for alphabet EBCDIC. 
By requiring the word ALPHABET in a alphabet-name clause, the 
ambiguity is resolved. 
RESERVED WORDS 


The following new reserved words have been added: 


ALPHABET END-DELETE END-UNSTRING 
ALPHABETIC - LOWER END-DIVIDE END-WRITE 
ALPHABETIC-UPPER END-EVALUATE EVALUATE 
ALPHANUMERIC END-IF EXTERNAL 
ALPHANUMERIC-EDITED END-MULTIPLY FALSE 

ANY END-PERFORM GLOBAL 
COMMON END-READ INITIALIZE 
CONTENT END-RECEIVE NUMERIC-EDITED 
CONTINUE END-RETURN OTHER 
CONVERSION END-REWRITE PADDING 
CONVERTING END-SEARCH REPLACE 
DAY-OF-WEEK . END-START STANDARD-2 
END- ADD END-STRING TEST 
END-CALL END-SUBTRACT TRUE 


END-COMPUTE 
STANDARDIZATION PROCESS 


There are two committees which work on defining COBOL. The 
CODASYL COBOL Committee has the responsibility of developing the 
language. The ANSI X3J4 committee has the responsibility of 
standardizing the language. When working on a new standard, X3J4 
can adopt specifications from either the previous standard or 
from the Journal of Development which reflects the work of the 
CODASYL COBOL Committee. If there is a problem with the JOD 
specifications, X3J4 must either subset the specifications from 
the JOD so that the problem does not appear in the standard cr 
request that CCC resolve the problem. Both committees have 
representatives from implementors, users, and government. X3J4 
currently has 23 members and holds six 4-day meetings each year. 
The work on the next standard is nearing completion as the 
committee has achieved the necessary two-thirds vote on its 
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formal letter ballot to forward the document to its parent 
committee, X3. X3, in turn, votes to send it out for an official 
public comment period of at least four months. The X3J4 
committee will review all comments received during this period. 
After all negative comments have been processed, the X3 committee 
votes on sending the draft proposed standard to ANSI to be 
formally processed as a new standard. 


During the standard revision process, X3J4 has published 
information concerning its work in COBOL Information Bulletins. 
The latest one was CIB 19 which was published in May, 1980. 
Comments concerning the draft standard will be officially 
requested during the public review period; however, comments 
may be submitted earlier to: 


Chairperson, X3J4 
CBEMA 

1828 L St. N.W. 
Washington, D.C. 20036 
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SYSTEM PERFORMANCE AND OPTIMIZATION TECHNIQUES 
FOR THE HP/3000 


John Hulme 
Applied Cybernetics, Inc. \ 
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INTRODUCTION 


The purpose of this paper is to introduce the reader to certain 
techniques which can improve system performance, throughput, and 
run-time efficiency on HP/3000 computers. These improvements will 
typically reduce response time substantially and generally increase 
data processing productivity. 


This paper will not simply tell you what to do and what not to do. 

In many cases there are trade-offs involved and it is more important 
to understand the principles behind the techniques than the techniques 
themselves. And because analogies often help us to learn by giving 

uS a new perspective, we will make use of a non-data-processing 
illustration. 


SOME BASIC PRINCIPLES 


The first thing to understand is that any given computer can execute 
a finite number of instructions in a fixed amount of time. When 
that theoretical limit is reached, no amount of tuning can "squeeze" 
extra instructions into the computer. For the most part, however, 
computers do not bog down because we ask them to do too much, but 
rather because we cause them to trip over themselves in the process 
of doing it. 


This leads to the second important principle: At anv moment the 
computer is either 1) doing productive work. 2) getting ready to do 
productive work, or 3) waiting on some external action before it can 
proceed with productive work. As a program is initiated, thereby 
causing a certain sequence of instructions to be executed, we will 
call the execution of those instructions’ "productive work". Whether 
the "productive work" is really necessary or not, and whether it is 
efficiently or inefficiently organized, are issues to be addressed 
later. But a more significant fact of computer life is that usually 
only a small percentage of the computer's time is spent executing 
application program instructions. 


A_CRUDE MODEL 


To illustrate these principles, imagine a "library for the blind". 

The librarian sits behind the desk waiting for a blind person to 

walk into the library. This is the "waiting period". When the 

blind person arrives, the "getting ready period begins. The blind 
person tells the librarian which book to retrieve and by one method 

or another the book is retrieved. The librarian now begins the 
"productive work" phase, reading to the blind person from the selected 
book. When the reading is completed, the librarian may return the 
book to the shelf or leave it on the desk. Then a new waiting 

period begins. 
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If the library is a busy one, we can imagine that one or more 
assistants might be hired to transport the books between the librar- 
ian's desk and the book shelves. Let's imagine that there is one 
assistant for each wing of the library. The librarian can do more 
productive work (reading to the patrons), spending less time getting 
ready (still looking things up in the card catalog, but now dealing 
with the assistants instead of transporting books). A new type of 
waiting is introduced, however: waiting for assistants to bring 
pooks back. 


In this analogy, the librarian represents the computer's central 
processing unit (CPU), by which all the productive work is accomplished. 
Like our imaginary library, the HP/3000 has only one CPU. To improve 
trroughput we must maximize the CPU's productive time. 


cach patron represents a log-on session or jor. The librarian's desk 
represents the computer's main memory. It is cf a limited size, 
merely a workspace, in comparison to the stacks of book shelves which 
correspond to the mass storage devices. Finally, each assistant 
represents an i/o channel transferring data to and from disc, for 
example. 


While illustrating some important concepts, this analogy does not 
accurately model the run-time environment of the HP/3000, or any 
other computer. How could we refine the model to make it more realistic? 


THE MODEL REFINED 


At the risk of distorting the human situation, let me suggest four 
refinements which make our model more nearly resemble the actual 
computer processes: 

1. The "library" should be regarded as a collection of 

a) read only instruction manuals and reference tables (pro- 
grams and constants) and 

b) numerous loose leaf volumes (files) containing sheets of 
current figures and data (records) which may be periodically 
replaced, revised, removed, or added to. 

2. The "librarian's " job should be generalized to include any type 
of service that can be performed on the basis of preprinted 
instructions and supplied data. 

3. The computer always deals with a copy of whatever is stored on the 
disc, and usually just a few records at a time. So let's imagine 
that instead of asking a library assistant to fetch a particular 
book, the librarian will specify a limited number of paragraphs 
or data sheets and will ask the assistant to bring a photocopy 
of the desired paragraphs (colored paper for instructions; 
white paper for data). 

4. Because the processing speeds of a computer are so great, our model 
operates in slow-motion by comparison. Allowing that tne librar- 
ian can do in one hour what an HP/3000 can do in one second (i.e., 
using the scale of one hour for each second), the assistant could 
handle 20 to 60 requests per hour, and the equivalent of a 6C-word- 
per-s.inute typist could enter one character every 12 minutes. A 
22CC-baud rate would be equivalent to a maximur of 5 characters 
transmitted per minute, and a €600-line-per-minute printer would 
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correspond to one line every 6 minutes. 


SLOW-MOTION PERFORMANCE SIMULATION 

Visualize this scenario from the patron's point-of view (refer tc 
figure 1): You walk into the library, find an empty cubicle (terminal), 
and make yourself comfortable. You begin to formulate and transmit 
your. library card number and password (log-on) at the rate of no more 
than 5 characters per hour. (If it will relieve the agony, you may 
imagine that you spend the time drawing very large, very elaborate 
block letters). Depending on the facilities available in the 
cubicle, you will either transmit each letter as it is formulated 

or accumulate several characters (maybe even hundreds) and transmit 
them in a burst. In either case, you transmit each letter separately 
by ringing a bell, and, when you have the librarian's attention, 
holding up the card with the letter on it. The librarian records 
each character of your message on a notepad corresponding to your 
cubicle, then continues with his other business. Finally you send 

a character which means "that's tne end of what I'm sending you". 


The librarian eventually verifies that you are a qualified user of 

tne library and sends you back a standard message which allows you to 
proceed. This process may require the librarian to send his assistant 
to the book shelves several times, e.a., to get a procedures manual, 
index of users, table of passwords, welcome message, etc. 
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Next, you painstakingly tell the librarian the name of an instruction 
manual] (procrar) you want him to follow in performing some service 
for you. He has the assistant get him a copy of tre first paracrsfp: 
(seaqment) of the instruction manual (unless a copy nappens to be 
sitting somewhere on the desk already). he also gets a copy, ycur 
own personal copy, of a worksheet (your data stack) associated witn 
tre specific instruction manual you have specified. 


In case there is not enoucgh empty space on the desk for these papers, 
the librarian first clears some space by either a) throwing away one 
of the instruction sheets, b) having his assistant put the worksheet 
for some other patron in a special holding file (virtual memory), Or 
c) having his assistant take one of the data sheets back to the 
loose-leaf it was copied from and replace the original with the new 
version. 


The librarian now goes to work following the instructions you have 
recuested. This will continue until a) he comes to a point in thre 
instructions which specifies he is to send certain information to 
you and/or ask you for additional input; b) he comes to the end of 
the page or is otherwise instructed to refer to another page, one 
which is not currently on the desk ; c) the instructions require 
thet information be fetcned from the book shelves, taken there 
to be filed, or sent to some output device; d) a predefined lencth of 
time elapses ( a 500 microsecond quantum corresponds to one-half 
hour in our model); or e) the librarian completes his assignment énd 
G@isposes of your worksheet. 


In any of these cases, the librarian will go back to work for one 
of the other patrons, provided he has ali the resources necessary 
to do so. If not, he will wait (until tne necessary information is 
fetched by the assistant or transmitted by one of the patrons). 
Depending on what you've asked the librarian to do, and how busy 

he is doing things for the other patrons, it may taxe hours or even 
days before he gets back to you. But then again, it may take cays 
for you to formulate the equivalent of one screen of input, too 

(at the rate of 5 characters per hour). 


THROUGH THE EYES OF THE CPU 


Now let's reverse roles and look at the situation from the lisrar- 
ian's perspective. Try to imagine yourself as a cain, unemotional, 
purely methodical being who is never responsible for mistakes because 
he does precisely as he is told. You couldn't care less if someone 
gets poor response time; you aren't to blame, because you only rest 
when there's nothing for you to do. In fact, you purposely set 
things aside during peak demand periods to do in your spare time. 

But you can't take credit for that either-- you're only following 
directions from the MPE handbook. 


There's the bell in cubicle five. He's holding up 


2:Ca:17 
Write it down on memo pad #5 (line buffer). 


Ring! 
the letter "R". 
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23:10:26 


Here's the library assistant with the record session #72 
requested. Oops! The worksheet for session #12 has been 
set aside (swapped out to the system disc). Send the 
assistant for it and wait a minute. 

A ring from cubicle #&. That's a carriage return. ime to 


reinitiate session #2. Make a note to send the assistant 
for the worksheet when he gets back. 


vVait some. 
Wait some more. 


Oh good, something to do (the okserver's feelings, not 
yours). A ring from cubicle #3. A "7". Write it down. 
Here's the assistant. Put worksheet #12 on the desk. Send 
him pack for worksheet 7@&-- no, there's not room for it. 
Give him the worksheet for session #5 and send him to file 
it (we're waiting for input from cubicle #5). We'll sen3 
him for worksheet #8 next time. 


Okay, mow to cet to work on task #12. First set tne timer 
for 30 minutes. Now add I to J énd put the result in k. 
Move WS to W2. Move...hold it, there's anotner ring from 
#3. Say, that's only a few seconds...must be 4 block-mode 
terminal. Write down the "S$" and ao back to work. Move 

X te Y. Call the procedure "XFORM". Oh, it's on the des*: 
already-- it hardly ever gets tmrown out, that's because 
nearly every procram uses it. 


Another ring from cubicle #3. This time it's a minus sign. 
Continue with "XFORM". Convert the first letter of Y to 
upper-case. Now the second letter. Now the trird. Now 
the fourth. That's all. Return to the main program. it's 
still in memory. 


Move the new Y to F232. 


Another ring from cubicle #3. A field separator. Resure 
task #12. Perform FLAG-SeT subroutine. Tr's in anctner 
sarcvent, one that's not in memory. Make a note to seni for 
it. Suspend task #12 for a minute. 


Cubicle #3 again. Just a blank, but write it down anyway. 
That's "7-2-minus-field separator-space", so far. 
The assistant has finished filing worksheet #5. Send him 
now for worksheet #6. 

Cubicle #3. Another space. 

Interrupt from the printer saying the last line has printed 
successfully. Now reactivate the spooler job-- it's instruc- 
tions are still on the desk and so is the buffer containing . 
the print-line. Initiate i/o transfer. 


2-second wait. 
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2:11:47 


2:11:52 


2211259 


22:12:04 


Comment : 


Cubicle #3. A third space. 
12-second wait. 

Cubicle #3. A fourth space. 
12-second wait. 

Cubicle #3. A fifth space. 
12-second wait. 

Cubicle #3. A fielj-separator. 
5-second wait. 


Worksheet #6 is here. Send assistant to get a copy of 
FLAG-SET routine. Now to process this input from cubicle #6. 


Edit first field. Ok. Edit second field. OK. Move first 
field to Ri. 

Cubicle #3. The letter "H". 

Move second field to K2. Edit third field. Isn't numeric 


but should be. Transfer to error nandler in same seament. 


Cubicle #3. The letter "O". 

Prepare output to tell cubicle #& about error. Comment: Itis 
a shame, but since he's in block-mode, he'll have to retrans- 
mit the whole screen again, after correcting the error in 
field 3. And who is to say other errors might not be detected 
after that? And you, the librarian, can receive those 673 
characters, one every 12 seconds for nearly three hours. 

But you don't mind. It's only a joc. 

Cubicle #3. The letter "Vv". 

Finish putting error message in tne output buffer. Initiate 
transfer to cubicle #8. “Mark task #€ eligible to be swapped 
Out. 


Cubicle #11. The letter "P". 


Cubicle #3. The letter "E". 


FLAG-SET routine is here. Continue with task #12. Move 

4 to FLAG. Add 1 to COUNT. Exit back to mainline. What! 
The assistant had to fetch a separate segment just so we 
could do that? 


Oh, oh. Two block-mode devices transmitting 
Ld 


Cubicle #11. 
at once! Record the letter 
mRW 


Cubicle #3. The letter 


Stop, I've had enough of dinging bells! Tnis place sounds like 


a hotel lobby, not a library! 


13 


OBSERVATIONS 


As this analogy indicates, there are three factors which reduce 
overall system performance: 

a. unnecessary disc i/o (most serious), 

b. unnecessary terminal i/o (too common), and 


Cc. ata CPU usage (rarely the problem in an on-line environ- 
ment. 


EXCESSIVE DISC _ I/O 


The primary cause of excessive disc i/o is inadequate main memory 

to hold the required work space (stack and data segments) for each 
concurrent process, plus all frequently refrenced program segments, 
plus a reasonable mix of infrequently referenced program segments. 

The HP/3000 is very good at nandling multiple concurrent users, even 
when they won't all fit in memory together. In fact, the use of 
virtual memory, combined with a well-designed algorithm for selecting 
which seqment to overlay, allows the system to operate efficiently 

even in cases where a single program exceeds the limits of main memory. 


The thing to remember, however, is that code segments put a relatively 
small load on the system while data segments put a potentially disas- 
trous load on the system. In the first place, code seaqments can be 
split up and made as small as the programmer wants them to be. 
Secondly, they do not have to be rewritten to virtual memory when the 
main memory space is to be re-used; they are simply overlaid. Data 
segments, cn the other hand, tend to expand, and can be split only 
with difficulty. Since their contents may change, they must be 
rewritten each time the process is swapped out, and reread each 

time it is swapped becl: in. Finally, whatever data space is resuired 
must be repeated for each process that is active. Therefore, if 

you are Supporting 20 terminals, any reduction in data requiremerts 
would produce 40 times the benefit that an ecuivalent reduction in 
ccde rectuirements would produce. 


aside fror uporading 
can be averted by: 

@€. reducing the number of concurrent processes 
option), 

c. reducing the average stack or data segment size, 

c. reducing the size of the average program segment, 

d. organizing program segments better so that out-of-segment 
transfers occur less often to non-resident segments and so 
that often-used code is collected in compact segments that 
are likely to stay in memory, or 

@e. some combination of the above. 


to @ larger machine, a shortage of main mencr,, 


(not an attractive 


When adequate main memory is available, swapping is unnecessary, 

and disc accesses (which are very expensive in terms of time) will 

be expended strictly for data retrieval and storage. Once swaprine 
begins, the computer's "productive" activities 3re at the mercy of 
"waiting". In the worst case, "threshing" occurs, which means trat 
every time a session gets a turn at execution, either the progras 
semen = h3s been overlaid or the session's work space has been swerped 
out. 
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It is worth noting that the use of IMAGE (or of KSA) causes the 
allocation of extra data segments. Specifically, each IMAGE data 

base that is open requires a data segment large enough to hold one 
copy of the root file plus four complete data base buffers. If a 
program accesses multiple data bases, or if the root file or buffers 
are large, the memory requirements will be substantial, and witn 

many terminals running data base applications, the memory reguirements 
can add up very quickly. Granted, the advantages of using a powerful 
access method may outweigh the costs of additional memory demands, 

but such tools should be used carefully and not indiscriminantly. 


It should also be noted that the use of block-mode recuires extensive 
buffers in the stack (at least as larce as the largest screen to 

be transmitted). The use of VIEW/302°2 may add another 6000 bytes 

of buffer in each user's stack, not to mention the extra cata segments 
created by its use of K3AI.. If you heve 20 users, this amounts to 
120K extra bytes of memory or more. 


EXCESSIVE TERMINAL I/O 


fajor causes of excessive terminal i/o include the following: 

a. Transmitting unnecessary characters (trailing spaces, leading 
zeroes, insignificant digits, etc.) to tne computer, a 
necessary conseguence of fixed-format or block-mode input. 

b. Transmitting the same data to the computer more than once, 

as occurs in block-mode when a wnole screen is retransmitted 
to correct an error in a single field. 
Retransmitting to the computer data which has not been changed 
since it was received from tne computer. Thiz too is tre 
result of block-mode transmission. 

d. Repeatedly displaying prompts at the terminal instead of 
using protected backcround forms. 

Since each character of input consumes critical resources, every 
effort should be made to ensure that only significant data -s 
transmitted (nce extraneous zeroes or spaces and only those fields tat 
are new or have been modified). 


It is not only wasteful of computer power, but also destructive of 
operator morale, to wait until a whole screen of data has been 
entered and transmitted to the computer before discovering that 
the screen is invalid due to a duplicate key or an unrecognized 


search-item value, etc. 


t is etunlly inefficient (for the computer, that is) to display 
creer of data, have the operator update a single value én 
nevit the wricle screen back to the computer. in én extrene CHSse, 


ec cculd amount te over 4 thousand characters transmitted just 


to change one or two characters. 


tn 
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EXCESSIVE CPU USAGE 


Besides the costly i/o overhead, it is altogether possible that a 
retransmitted screen will be completely re-editted, values packed and 
unpacked, and fields reformatted even though only a single field 

was updated, and maybe even if nothing was updated. This is one 
cause of unnecessary CPU usage. 


Most editting and reformatting done in COBOL subroutines requires 
excess usage to begin with, and it is far better to allow such work 

to be done in SPL subroutines, where it can be done efficiently. 
Including such subroutines in the COBOL programs also causes bulkier 
segments, which is likely to increase the need for swapping. The 
best solution is to incorporate all editting within the terminal- 
handling module itself, since it is already being shared by all 
on-line programs and is therefore likely to remain constantly in 

main memory. There are a multitude of factors which can unnecessarily 
increase the so-called "productive work" which the CPU has to so. 
Because computers are seldom CPU-bound in an on-line environment, 

few people exert the effort to truly optimize CPU performance anymore. 
Whenever it is a problem, more careful analysis of the program(s) 

in question will usually yield a more efficient method of solving 

the application problem. 


Often, more careful analysis will also yield a better solution from 
the point of view of disc i/o as well, both in terms of swapping, 
code-segment switching, and data retrieval and storage. One word 

of warning, however: more efficient solutions (CPU-wise) are very 
often more complex, and to the extent that they increase stack space, 
or code-segment size, or they require more transfers from one 
code-segment to another, they may prove counter-productive. 


One situation in which heavy CPU usage can be very detrimental is 
wnen on-line processes are competing witn batch applications for 

CPU resources. This can be vividly illustrated by running a COBOL 
compile, an Editor GATHER ALL, a sort, or the BASIC interpreter at 
the same time on-line programs are running. Block-mode applications 
exhibit many of these same tendencies and can severely impede 
response-time for character-mode applications when botn types are 
running concurrently. 


SPECIFIC OPTIMIZATION TECHNIQUES 


1. Resegment programs so that no segment exceeds %5°00 words. 
Set the blockmax parameter on IMAGE schemas as low as possible. 
. Use extra data segments where possible and free trem up when finished, 
rather than increasing stack space for large temporary curfers. 
4. Don't keep files cpen unnecessariiy. 
5S. Don't abuse IMAGE: 
a. eliminate sorted chains where possitle. 
b. carefully evaluate tradeoffs of increasing or eliminating 
secondary paths in detail data sets. 
c. use "€;" or at least "*;" for item lists wrerever possizle. 
d. only use binary keys (in master file) when overlapping 
keys can be avoidid. 
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e. don't let synonym chains get very long. 

f. when loading master data sets, store only primaries on 
the first pass, making a seccnd pass for secondaries. 

g. keep master data sets less than 85% filled. 

h. periodically reorganize detail data sets that have long 
chains associated with a frequently-accessed path (puts 
consecutive records in the same physical block). 

i. keep the number of data sets in a data base as smali as 
practical without requiring many programs to open multiple 
data bases. 

j. keep IMAGE record lengths to a minimum. 

Have operators exit programs when not in use. 

Use a field-oriented terminal handler whicn performs standard 
edits for you. 

Use formatted screens with protected background whenever the 
application is appropriate to such use. 

Keep terminal i/o buffers small; if possible, eliminate block-mode 
i/o altogether. (Don't use block-mode and character-mode i/o at 
the same time.) 

Don't use VIEW without a lot of memory. 

Don't use DEL at all. 

Run CPU-intensive jobs (including compiles, preps, and Editor 
GATHER ALL) when on-line applications are not running, or at least 
run them in a lowér-priority sub-queue. 

Set the system quantum for a shorter period than recommended in the 
MPE manual (but don't overdo it-- some experimentation may be 
necessary). 


APPLIED CYBERNETICS INC. 


Information Management Specialists 


408 356-7296 
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Production 
Management/3000 
overview | 


The efficient management of production 
resources is made possible using the 
techniques of Capacity Requirements 
Planning (CRP) and Shop Floor Control. 
These techniques build upon a manufacturer's 
production schedule, an accurate description 
of the facility, and the steps necessary to 
fabricate or assemble each part; as well as 
information about the status and location of 
each work order. An effective method of 
dealing with these fundamental issues can 
provide a manufacturer with a sound 
foundation for success. 


Production planning and 
control system 


Production Management/3000 is a standard 
application product which helps manage the 
planning and control functions of a discrete 
manufacturing company. The objectives of the 
product are to minimize inventory investment 
while maximizing asset utilization, shipment 
performance, and customer satisfaction. 


Production Management/3000 is a fully 
integrated system and addresses the following 
areas: 


Routings and Workcenters—Maintains 
descriptive, cost, and planning information 
about each workcenter in a manufacturer's 
production facility and the routing sequence 
necessary to build each assembled or fabricated 
part. 


PRODUCTION MANAGEMENT / 3000 


Work-In-Process Control—Provides a 
variety of tools to analyze the progress of the 
manufacturing plan and allows production 
managers to fine-tune the shop floor control 
process. 


Work Order Scheduling—Calculates start and 
completion dates for each sequence of every 
production work order under the control of 
Production Management3000. 
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Shop Floor Dispatching—Maintains 
production priorities to ensure that 
manufacturing resources are devoted to the 
right tasks at all times. 


Work Order Tracking—Records the progress 
of each work order as well as related labor 
charges and exception information. 


Capacity Requirements Planning— 
Anticipates labor and other manufacturing 
resource requirements on the basis of 
in-process production work orders and/or 
planned work orders from a Material 
Requirements Planning system. 


WORK ORDERS 


WORK 
ORDER 


| 





CAPACITY ROUTINGS 
REQUIREMENTS <+——— AND 
PLANNING WORKCENTERS 
LABOR AND STANDARD 
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SCHEDULING 
WORK 
ORDER 
TRACKING 


SHOP WORK- 
FLOOR IN-PROCESS 


DISPATCHING CONTROL 


! ! 


PRIORITIZED INPUT: 
QUEUE OUTPUT 
LISTS ANALYSIS 
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The shop calendar 


An important factor in the creation of a detailed 


production plan is a definition of the work 


schedule for each production area. Production 


Management/3000 maintains a shop calendar 
which describes the work-day and shift 
schedules for each workcenter in the 
manufacturing facility. This calendar can be 
maintained on-line by shop management and 


can be modified at any time to reflect changes to 
the work schedule as soon as they are planned. 


The Production Management/3000 shop 
calendar describes schedules for up to three 
shifts per day, for as many months as 
necessary. 


In addition to a master shop calendar, a 

separate calendar can be created for any 

individual workcenter. All Production 

Management/3000 scheduling and planning 
‘unctions refer to the same set of shop 
alendars, providing a consistent basis for 
'etailed production planning and a simple 
reans of indicating holidays and planned 
‘ork schedules. 


Routings and 
Workcenters 


Features 

® On-line data base update. 

® On-line review of routing and workcenter 
information. 

® Standard, common, and alternate routings. 

= Capacity specifications of workcenters. 

® Cost specifications of workcenters. 

® Shop calendars. 


@ Standard labor und overhead cost 
calculation. 


Description 


An accurate model of the manufacturing 
facility and the procedures used to 
manufacture each product is essential to all 
production planning and control functions. 
The ROUTINGS AND WORKCENTERS 
module provides for on-line entry, validation, 
and maintenance of the information which 
forms the foundation for the operation of 
Production Management/3000. 





Describing the | 
manufacturing process 


Part number definition 


Each manufactured part, subassembly, and 
product is assigned a unique part number. This 
number is used throughout Production 
Management/3000 to access, update, and 
retrieve information about each item. Part 
information maintained in Production 
Management/ 3000 includes: standard yield 
percentage, standard run quantity, and part 
description. If desired, additional data items 
can be added through the use of the Production 
Management/ 3000 customization feature. 


Defining production operations 


Each basic manufacturing process can be 
described separately within Production 
Management/3000 and is assigned a unique 
operation number. Information such as average 
queue, setup, and unit run times as well as 
standard manufacturing yield is maintained for 
each operation along with a brief description of 
the procedure (i.e., drill, paint, test, etc.). 


These operations form the basis for 

describing the individual steps involved in the 
manufacturing process for each manufactured 
part number under the control of Production 
Management/3000. 
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Defining workstations 


Basis of CRP 
exception reporting 


The capability to define and maintain standard 
part routings and manufacturing workcenter 
descriptions is provided both in Materials 
Management3000 and in Production 
Management/3000. In situations where both 
Materials Management/3000 and Production 
Management/3000 are employed together, all 
facility and routing specifications will be 
defined and maintained through Production 
Management3000. In such cases, the 
ROUTINGS AND WORKCENTERS module of 
Materials Management/3000 will be disabled. 
Standard labor and overhead cost information 
will be provided to the STANDARD 
PRODUCT COSTING module of Materials 
Management/3000 from Production 
Management3000. 


For customers who choose to install Production 
Management/3000 after Materials 
Management/3000 is already in operation, 
information defined in the ROUTINGS AND 
WORKCENTERS module of Materials 
Management/3000 can be transferred to the 
ROUTINGS AND WORKCENTERS module of 
Production Management/3000 as a part of the 
normal system installation procedure. 


Describing the 
manufacturing facility 


Production Management/3000 views the 
manufacturing facility as a collection of 
workcenters, each of which shares common 
personnel, supervision, and/or floor space. 
Workcenters, in turn, are comprised of one 
or more workstations which represent labor 
or equipment used to perform each type 
of production activity. Depending upon 
the nature of each manufacturing facility, 


Wort Station Description 
NUMERICAL DRILL STATION METAL 
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Work Center Id 
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Start Up 
Unit Measure wT 
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Date 
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maddyy 


Wort Station Status 1 
€ Status < 1000 means available ) 


Defines standard 
waiting time at 
this workstation 
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individual people and/or pieces of equipment 
can be represented by separate workstations, 
or those which are more or less interchangable 
with one another can be grouped together. 


A workstation may be thought of as a location 
at which people and/or machines perform a 
particular type of activity needed to produce 
each part, assembly, or product. Information 
maintained for each workstation includes 
descriptive and control information such as 
labor and equipment capacity, average queue 
delay time, and the percentage of the normal 
queue which can be compressed for high 
prontty work. 


Additional information including average 
wage rates, production capacity, and the 
names of responsible managers can be 
maintained at the workcenter level. 


The information maintained for each 
workstation and workcenter is essential for 
realistic work order scheduling and tracking, as 
well as for the calculation of accurate standard 
labor and overhead cost information. 
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Alternate workstations 


In situations where a routing sequence for a 
part can be performed equally well at more 
than one workstation, the various alternatives 
can be specified by creating multiple entries 
having the same route-sequence number. On 
the shop floor, when each work order arrives at 
a production sequence for which multiple 
alternatives exist, Production Management/ 
3000 examines the workload in queue at each 
alternate workstation and then recommends 
sending the order to the one with the least 
hours of work waiting to be done. 


SEQUENCE 10 


1 


Alternate workstations 


Defining standard routings 
(Bills of labor) 


The sequence of operations required to 
produce or assemble an item constitutes the 
standard routing (or bill of labor) for that part. 


Each sequence in a part’s routing must be 


valid operation. The order of each operation 
within a part routing is controlled by the user- 
supplied route-sequence number. Any amount of 
descriptive text may be associated with each 
route-sequence. In addition, the user may 
enter the following information for each Transit 
sequence in the routing: 


= Descriptive and control information. 

® Machine, tool, and drawing references. 

# Setup and unit run times. 

s Transit time from the previous operation. 


This information provides the basis forall work Defining standard routings 


order scheduling, capacity planning, and shop 
floor control functions. 


Sta Rte 
5 3 . Alt 
associated with both a valid workstation anda Ple Ia 

Oprin Nor 
Drawing ld 


Setup Labor 
Wtido) 80 Kahu 2a 


Unit Run Labor 


SEQUENCE 20 


WORKSTATION __|_» WORKSTATION _,1 


2 


SEQUENCE 30 SEQUENCE 40 


WORKSTATION 
3 


OR 


WORKSTATION J» WORKSTATION 
4 6 


OR 
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Part Number 


Route 
Seq Noe 


Repair Parallel Next Seq 
Level Code Override 


ants a ioa 


Wort Station Work Center 


Tool Id 


URRENT TIMES IN HOURS 


Defines standard 
rework sequences 


Setup Schedule Code 


Setup Machine 


Unit Run Schedule|Code Unit Run Machine 


a 
L/m/8 


Joining sequence for 
paraliel paths 





indicates whether 
labor or machine 
hours are to be 
used for scheduling 
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Alternate part routings 


Alternate routings designed to take advantage 
of various equipment configurations or 
subcontractors can be defined in advance. Each 
alternate routing specified for a part must be 
complete and is independent of all other 
routings. When work orders are actually 
created, any of the specified routings can 


be selected. 
PARTA 
PRIMARY ROUTING | ALTERNATE ROUTING 
einen tenia ietandietitineten tien > cocoon 
| CO 
| ! | 
, Cut i DRILL | CUT 
| | 
l : | 
| | 
, 
| BEND “*——  DEBUAR | | 
| ! 
| | | 
| | | 
| | 
I | | 
INSPECT | 
| | | 
a a set Ses Geer ot ees | Ue os ee Serene SS 


Jternate routings 


Parallel routing sequences 


Production Management/3000 provides the 
capability to schedule and control multiple 
parallel production paths for each individual part 
number. This allows related subassemblies to 
be manufactured on a single production work 
order and then to be combined without using 
intermediate inventory levels. Any number of 
parallel paths can be specified for each part, 
and each can include as many production 


“join” for assembly. 


| PATH 3 LEAD TIME J 
{ TOTAL PART LEAD TIME j 





Parallel routing paths 


sequences as necessary. Each production path 
is identified by a user-defined parallel code 
attached to each routing sequence, and by a 
specification of the sequence at which paths 
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Production Management/3000 provides for the 
scheduling and control of parallel production 
paths to minimize overall manufacturing lead 
time, and to keep work-in-process inventory 
levels to a minimum. In certain types of 
manufacturing environments, the use of 
parallel production paths can result in 
significant reductions in inventory carrying 
costs. 
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Employee information 


Employee information in Production 
Management/3000 is used primarily for the 
validation of direct labor charges. An employee 
identification code must be assigned to each 
employee who will be charging labor time to 
work orders. As labor is reported, Production 
Management/3000 verifies that a valid ID code 
is entered with each transaction. Additional 
information such as location code and 
overhead account can be maintained for each 
employee, for use as reference information. 


Common part routings 


Production Management/3000 allows any 

part to use the routing defined for any other 
part as if it were its own. All Production — 
Management/3000 functions can automatically 
refer to the common routings for such a part. 
This feature eliminates the need to define 
identical routings for each of a number of 
similar parts which utilize the same basic 
manufacturing process. 


An additional advantage of this approach is 
that when the common routing changes in 
any way, only one master routing needs to be 
modified in order to effect the change for all 
parts which refer to it. This can represent a 
substantial reduction in effort and can help to 
ensure the consistency of manufacturing 
specifications. 


Standard Product Costing 


Production Management/3000 calculates 
standard labor and overhead costs for each part 
under its control. These costs are calculated 
using the run quantity for each part, labor 
setup and run times from the standard 


routing, and overhead and average wage 
rates from each workcenter. If more than 

one routing exists for any part, the primary 
routing is used (i.e., any alternate routings are 
ignored). This information is available to the 
STANDARD PRODUCT COSTING module of 
Materials Management/3000 for use in the 
standard cost roll-up. For a detailed discussion 
of STANDARD PRODUCT COSTING, please 
refer to the chapter describing Materials 
Management/3000 earlier in this document. 
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PART C ———— PARTA ~<t#————— PARTB 


Common routings 
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Input/Output analysis 


The Input/Output analysis report provides a 
means of evaluating recent performance both 
in absolute terms, and in the light of previously 
planned production requirements. Planned 
input and output are presented alongside 
actual or observed input and output for each 
recent time period, and cumulative changes in 
backlog are calculated for easy analysis. Early 


O| PRINT DATE 
RUN DATE 


04/02/81 
04/02/81 


CO! WKCTR METAL 
WKSTN DRILL 
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-PERIOD- 
QO | DATE 

03/24/81 0 

O| 03/26/81 .5 

03/28/81 .0 

| 03/30/81 -0 

O 04/01/81 .0 

| 04/03/81 0 

| 04/05/81 0 

O; 04/07/81 -0 


| Standard fabor hours 
Scheduled to arrive 
OC | af this workstation 





identification of production bottlenecks 
through the use of Input/Output analysis 
allows corrective action to be taken before the 
overall manufacturing plan can be seriously 
effected. 
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this workstation 
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Input/Output report 


Work-In-Process 
Control 


Features 
= InputOutput analysis. 


8 On-line work order status and 
history reporting. 


® Work order priority control. 

® Work order partialling. 

® Work order routing modification. 
# Data archiving and retrieval. 


Description 


WORK-IN-PROCESS CONTROL provides 

a set of reports and functions which allow 
production managers to monitor the progress 
of the manufacturing plan and to override the 
automatic scheduling and control functions of 
Production Management/3000 in order to 
accommodate special situations. 


When factors beyond the scope of automatic 
planning and control arise, Production 
Management/3000 allows priority and routing 
decisions to be included directly into the 
manufacturing plan. This capability removes 
the need to ‘‘work around the system” in 
special situations; thus integrating the best of 
automatic scheduling and control with 
management discretion. 


Life cycle of a work order 


All planning and control functions of 
Production Managemenv/3000 revolve around 
individual production work orders. Taken 
together, all planned and open work orders 
constitute the current production schedule. In 


order to ensure that the detailed production 
schedule supports the due dates of all known 
requirements, Production Management/3000 
assumes that infinite production capacity is 
available at all times. CAPACITY 
REQUIREMENTS PLANNING evaluates all 
such requirements over time in order to 
identify schedules which call for more capacity 
than is actually available. By evaluating the 


RELEASED 
WORK ORDERS 


fit 


IN QUEUE 


IN TRANSIT 


; 


COMPLETED 
WORK ORDERS 


Production lite cycle 


CAPACITY = 16 HRS 
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resource requirements stemming from each 
work order, capacity requirements and production 
priorities can be determined so that specific 
actions can be recommended by Production 
Management/3000. 


Each Production Management/3000 function 
uses the current production schedule in a 
coordinated way as individual work orders 
proceed through the following life cycle: 


IN-PROCESS 
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Creating partial work orders 


Production Management/3000 provides for the 
separation of work orders into multiple partial 
work orders at any time. Partial work orders 

are created by specifying the number of units 
from the parent work order which are to be 
separated, and the production sequence from 
which they are to be taken. A separate copy of 
the work order is then automatically created 
which has a routing identical to that of the 
parent. 


Once created, partial work orders become 
independent of their parent work orders 

and can be assigned separate due dates 
andor priorities. For accounting and material 
planning purposes, all related work orders carry 
the same order number and are distinguished 
from one another on the basis of the partial 
number assigned to each. Any number of 
partials can be associated with a single work 
order number, and partial work orders can be 
further sub-divided if necessary. 


Labor reporting and 
maintenance 


Direct labor hours reported on the shop floor 
can be reviewed by employee, work order, or 
workcenter. Modifications can be applied to 
any individual charge, if necessary, prior to the 
utilization of these records for job costing or 
other reporting purposes. 


Work order status reporting 


The current location and status of each work 
order in process is available at all times for 
on-line analysis and review. Work-in-process 
status can be reported either on CRT screens or 
printed reports by: 


® Individual work order. 

s Workstation or workcenter. 
= Operation number. 

# Part number. 


Order routing modification 


Production Management/3000 provides the 
capability to modify the order routing for any 
single work order to accommodate special 

situations (such as subcontracting) without 


changing the standard routing for the associated 


part. Such changes are applied to the copy of 
the routing which is made at the time each 
work order is scheduled (see the section on 
WORK ORDER SCHEDULING later in this 
chapter). 


Existing production sequences can be modified 
or deleted and new production sequences 


can be added at any point in the routing. Work 


orders which are modified in this manner are 
immediately rescheduled in order to ensure 
that all changes are accurately reflected in the 
detailed production schedule. 


CRE f TIAL 


Create a Partial Lol -REATE PAR 
ueuet) Orders 9 ‘Lo Pa Step 4 Gtep kt +} Step~. 3 Peie eae” 


CUPPENT LOT 


Or ger Partial Operation 
Humber Number Number Date [n Time in 
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New Partial Quatity 
Number Partialed 


Sequence from 
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Creating a partial order 
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work Order RDES STAT 
Order Chg Lot Stop Printed Both 
Overview Status Report EXIT 


Order @ Part Number Description 


w01 7658 15465-18955 REAR PANEL FRAME 


--Seheduled-- 

Frtial Wort Wor b Pee Beg End uty aty Prtial 
Number Center Station Oprtn Late Time Date Date in Bonus Stat Parent 
METAL NCOPILL DRLY 06/15 03:36P 06/15 06/16 50 0 5000 
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Quantities added 
at each sequence 


Current location Quantities moved in 
of work order from previous sequences 





Reporting work order status 
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Infinite capacity assumption 


For purposes of work order scheduling, 
Production Management/3000 assumes that 
infinite production capacity is available 

at all times. Each work order is scheduled 
independently and requirements in excess of 
available capacity are then identified by the 
CAPACITY REQUIREMENTS PLANNING 
module (see the discussion of CRP later in this 
chapter). This procedure ensures that detailed 
production schedules will support the overall 
master schedule, and that modifications to the 
plan based on capacity constraints will be made 
in a coordinated manner through the materials 
management function. 


QUENCE 10 


Seta? x 
*) 


‘ou 
‘. 


Components of lead time 


Work Order 
Scheduling 


Features 

® Backward or forward scheduling. 
« Infinite capacity scheduling. 

® Work order specific routings. 


= Overlapped, compressed, and split 
sequence scheduling. 


® Partial work order scheduling. 
# Parallel path scheduling. 


PARTA 
SEQUENCE 


10 CUT 

20 DRILL 

30 BEND 

40 DEBURR 
50 INSPECT 


STANDARD ROUTING 


Standard Routing and Order Routing 


OPERATION 


The scheduling calculation 


Lead time requirements for each work order 
are calculated by accumulating the specified 
transit, queue, setup and run times for each 
production sequence. 


Backward and forward scheduling 


Once sequence lead times have been 
calculated, should-be start dates can be assigned 
to each production sequence either by 
“backward scheduling” from a user-supplied 
order due date, or by “forward scheduling’ 
from a user-supplied order start date. The 
dates are established by calculating actual 
elapsed time required to perform any 
production sequence and by examining 

the shop calendar for each workcenter to 
determine the number of working hours 
scheduled for any given date and shift. 


Description 


Work orders can be created as a result of 
transactions from Materials Management/ 
3000, and/or directly within Production 
Management/3000. As each work order is 
created, a unique copy of the standard part 
routing for that part is made and is associated 
with the order. This order routing can then 


Parallel production paths 


When parallel production paths are defined 
in the routing for a part (see the ROUTINGS 
AND WORKCENTERS section earlier 

in this chapter), each path is scheduled 


independently so that all will be ready for the 
joining sequence at the same time. In this way, 


inventory levels at all points in the 


manufacturing cycle can be maintained at the 


lowest possible levels. 
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be modified as necessary to indicate unique 
deviations from the standard routing 

(refer to the discussion of “Order routing 
modification’ in the WORK-IN-PROCESS 
CONTROL section earlier in this chapter). 


Using the due date of the work order asa basis, 
scheduled start and completion dates/times are 
calculated for each production sequence. Work 
orders are automatically rescheduled when- 
ever their due dates or other specifications are 
modified. These schedules form the basis for 
the evaluation of production priorities as well 
as other planning and control functions. 


WORK ORDER #1234 FOR 100 PART A DUE DEC. 1 


SEQUENCE OPERATION 


10 CUT 

20 DRILL 

30 BEND 

40 DEBURR 
50 INSPECT 


START COMPLETE 
DATE DATE 


NOV. 10 NOV. 13 
NOV. 15 NOV. 24 
NOV. 25 NOV. 27 
NOV. 28 NOV. 30 
NOV. 30 DEC. 1 


ORDER ROUTING 
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Shop Floor 
Dispatching 


Features 

8 Routing Lists. 

® On-line review of workcenter status. 

® Dispatch lists by workstation or workcenter. 
# On-line priority calculation. 

® Multiple dispatching rules. 

# Manual priority overnde. 


Overlapping, splitting, 
and queue compression 


Production Management 3000 provides for 
three methods of reducing the manutacturing 
lead time fora part below that which results 
from the scheduling calculation described 
above: 


Overlapped sequences—Are those where 


some part ofa work order is moved on to begin 
the next production sequence before all units 


SEQUENCE 10 


QUEVE SETUP | RUN 





Overlapped scheduling 


Description 


The SHOP FLOOR DISPATCHING 

module provides the tools to ensure that 
manufacturing resources are devoted to the 
right work orders at all times. The SHOP 
FLOOR DISPATCHING module evaluates 
production priorities dynamically on the basis 
of up-to-date status information and makes 
these priorities visible when needed on the 
shop floor. 


on the work order have been completed. The 
effect is to “overlap” process times al two 
sequences and to reduce the overall elapsed 
time required for completion of a work order. 
Overlap can be specified either for individual 
routing sequences or for all sequences ina 
standard part routing. 


Split sequences—Are those where more 

than one person or machine pertorms work 
concurrently ata single production sequence. 
The number of such people or machines can be 
specified tor any sequence ota part's routing, 
which has the effect of reducing the processing 
portion of elapsed lead time. 


Queue compression—Is a means ot 


pre-expediting a work order by assuming less 
than standard queue times w hen calculating 


SEQUENCE 20 


TRANSIT QUEUE SEF UP 


TRANSIT 
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scheduled start dates tor cach production 
sequence. Since these dates form the basis tor 
the assignment of relative priorities amony 
work orders in queue, this has the effect of 
assigning the compressed work order a higher 
priority at cach sequence than it would 
normally hav v. This is accomplished by 
specifying a “queue compression factor” fora 
work order which indicates the percentage of 
the standard queue which is to be removed for 
scheduling purposes, 


SEQUENCE 30 


QUEUE SETUP | RUN 
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Work order priority 
calculation 


The relative priority of each work order in the 
queue of each workstation is evaluated on the 
basis of a user-specified system value which 
defines the facility dispatching rule. Two such 
dispatching rules are provided by Production 
Management/3000: 


Scheduled start dates—The scheduled start 
dates assigned to each production step by the 
WORK ORDER SCHEDULING module are 
compared with one another, and higher 
priorities are assigned to work orders with 
earlier dates. 


Critical ratio—Priorities are based upon the 
ratio between the remaining lead time for each 
work order, and the elapsed time remaining 
until the due date for that work order. Work 
orders with lower critical ratios have higher 
priorities. 


In either case, these priorities can be 
overridden, as necessary, by user-specified 
priority assignments. 


When personnel or machines become 
available, a dispatcher can obtain a list of jobs 
currently waiting at any workstation or 
workcenter in priority order. This list can be 
produced either on-line or in printed form. 
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Releasing work orders 


Once shop management has determined that 
all materials and documentation necessary to 
begin production activity on a given work order 
have been assembled, the order is released to the 
queue of the first production sequence. At that 
time a Routing List is printed which describes 
the routing for that order in detail. This Routing 
List is added to the shop packet and travels 
with the work order through the production 
process. 


As work order movement or schedule changes 
laxe place, the Production Management3000 
data base is modified immediately to reflect the 
current status of work-in-process at all times. 
This dynamic model of the shop environment 
provides the basis for dispatching work 
according to the latest priorities whenever 
manufacturing resources become available. 
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Work Order 
Tracking 


Features 

® On-line work order status review. 

® Interactive step completion reporting. 
Factory Data Capture terminals. 
Partial work order tracking. 

Rework and scrap reporting. 
Exception reporting. 


Automatic load balancing. 


Labor collection. 


Description 


In order to effectively establish production 
priorities and provide shop managers with the 
information necessary to properly manage the 
manufacturing environment, Production 


Management/3000 must maintain an accurate ° 


picture of the status and location of each work 
order (or partial work order) at all times. Work 


order status information is collected on the shop 


floor at the time production activity actually 
takes place. Either simplified HP Factory Data 
Capture terminals or full-screen CRTs can be 
used for this purpose. 
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Selecting work orders from 
available queue 


As each work order is selected from queue for 
processing, its status is changed from in queue 
to in process using the WORK ORDER 
TRACKING function to indicate that itis being 
worked on. 


Dynamic shop floor dispatching ensures that 
priorities are up to date at all times, reflects 
changes to the overall production plan quickly, 
and can reduce or remove the need for manual 
expediting of hot jobs. 


Work order status can be modified in either of 
two ways: 


1) Asa result of completing an operation. 
When a production step completion is 
reported, the status of the associated work 
order is automatically changed from in 
process at the current sequence toi transit to 
the next sequence. 


2) Through the use of a specific transaction 
which modifies the status of a work order 
sequence to indicate that it has changed 
from one status to another (e.g., 1 transit to 
ui queue, oF in queue to in process). 


gs es 


Order Partial Qperation Rou 
Number Nuaber Number Se 


COpt 


New Status Code 


Order being entered. 
Order being scheduled. 
- Order hes been scheduled. 
Step in transit. 
Step queued to Wstn. 
(Order /Step) work in process. 
- Step ts on “HOLD”. 


Changing the status of a lot 
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Work order status reporting 


The current location and status of each work 
order in process is available at all times for 
on-line analysis and review. Work-in-process 
status can be reported either on CRT screens or 
printed reports by: 


® Individual work order. 

® Workstation or workcenter. 
® Operation number. 

® Part number. 


| Pa Sgep Rye ee Se. 


le o-> New Status --- 
Nbr Date Time 
a 


M4568 
=) (mmddyy) — Chham) 


Quantity In 
Mat COnly for receiving from 
IN TRANSIT). 


Step completion of a partial. 
Step compietion of a full order. 
Order completed. 

Order stopped (cancelled). 

Full Order “BOMBED" COTY-OUT*O>. 
Partial order “BOMBED®. 
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Production exceptions 


Information describing material failures, scrap 
losses, rework activity, or other exceptional 
conditions associated with each work order 
sequence can be collected and stored for 
analysis and review. This information can be 
entered at the time work orders are being 
tracked from one production sequence to 
another, or separately when exceptions are 
actually detected. 


Exceptions can be recorded either as free-form 
comments, or in terms of predefined codes 
which can be analyzed on a statistical basis. 
Exception codes and their definitions can be 
described at any time and can be either global 
or local in scope. Global exception codes can be 
used to describe unusual events regardless of 
where in the manufacturing facility they occur, 
while local exception codes apply only to those 
workcenters with which they have been 
specifically associated. 
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Production sequence 
completions 


As soon as each production sequence has 
been completed, the results can be reported to 
Production Management/3000 by the people who 
actually perform the work. The number of units 
completed, scrapped (lost), bonused (found), 
and reworked at each sequence can be entered 
via an HP Factory Data Capture terminal or a 
full-screen CRT. Related information such as 
direct labor charges, material failures, or other 
exceptions can be collected either all at one time 
as a part of the step completion transaction, or 
separately through individual transactions 
designed specifically for each type of 
information. 


Labor collection 


Production Management3000 provides the 
means to capture and record direct labor hours 
applied to each work order sequence. Labor 
hours are reported directly by shop personnel 
on the shop floor where work is actually being 
performed. As each entry is made, Production 
Management/3000 ensures that a valid 
employee ID and work order number have 
been provided. 


Labor hours can be entered at the time work 
orders are being tracked from one production 
sequence to another, or through separate 
‘transactions as work is actually performed. 
Labor charges can be modified at any time 
and accumulated hours can be reported by 
employee ID, work order number, or 
workcenter. 
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Completing a production sequence 
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Capacity 
Requirements 
Planning 


Features 

® Load projection by workstation. 
= Exception reporting. 

# Summary workcenter reporting. 
® Alternate load measures. 

= User-defined reporting periods. 
® Load detail reporting. 


SUGGESTED 
WORK ORDERS 
FROM MRP 


OPEN WORK ORDERS 
FROM Production 
Management/3000 
DATA BASE 


Capacity Requirements Planning 
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Balancing load among 
alternate workstations 


When successful completion of a production 
sequence is reported, the status of the work 
order is modified to indicate that it is in transit 
to the next production sequence. In cases 
where more than one alternate workstation 
has been specified for the next production 
sequence, Production Management/3000 will 
examine the amount of work in the queue of 
each alternate workstation. The work order 
will then automatically be made available in the 
queue of the workstation with the least hours of 
work waiting to be done and the user will be 
notified which workstation has been selected. 


This technique for load balancing provides 

for the even distribution of work among 
alternate workstations, and consequently for 
the reduction of lead times and inventory 
levels. 


Description 


CAPACITY REQUIREMENTS PLANNING 
can be used to plan labor and other 
manufacturing resource requirements over 
time at the workstation and workcenter 
level. It can use both existing work orders 


STANDARD 
PART 
ROUTINGS 


PRODUCTION 
CAPACITY 


PLAN 


REQUIREMENTS ———————»> 


PLANNING 


SHOP 
CALENDAR 


SEQUENCE 30 


SEQUENCE 20 


Load balancing 
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and production requirements suggested by 
Materials Management/3000 or another similar 
system. It provides a tool to highlight potential 
capacity constraints and provides information 
that can be used to help ensure that appropriate 
resources are available when needed and to 
smooth the workload for a manufacturing 
facility. 


LOAD PROFILE 





“SIGS Ea 


ei | 
Bee sll 
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Workcenter summary 
reporting 


In situations where direct labor personnel are 
trained to move among several different 
workstations in response to changing 
workloads, the true labor capacity of a 
workcenter may be less than the sum of the 
capacities of all workstations within it. In 
addition to workstation load reports, 
Production Management/3000 provides 
summary load reports for each workcenter 
which can help to identify resource constraints 
ret might not be visible at the workstation 
evel. 
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Calculation of requirements 


The calculation of manufacturing resource 
requirements is accomplished by scheduling 
each work order in the production schedule using 
part and order routings and the shop calendar to 
determine detailed load requirements for each 
work order. Each work order is scheduled 
independently of all others as if infinite 
capacity were available at all times. These 
detailed load requirements are then 
accumulated by workstation for each 
user-defined time period (days, weeks, 
months or quarters), forming a load profile for 
each workstation. 


PRINT DATE 
RUN OATE 


04/02/81 
04/02/81 


15:52 
15:00 


WKCTR METAL 
WKS TH DRILL 
MANAGER-J. FERGUSON 


~--PERIOD--- *MACHINE-- 
DATE LEN LOAO CAP 
04/02/81 
04/03/81 
U4/04/681 
04/05/81 
04/08/81 
04/09/81 
04/10/81 
04/11/81 
04/12/81 
04/13/81 
04/20/81 
04/27/81 
05/04/B1 


wd EN ee ee 
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eococoooo0ocoedce 
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LEGEND: 


Length: 'D' = Daily 


Workstation load profile 


Calendar days in 
reporting periad 


LABOR LOAD-~-------- 
RLSO OPEN 


CQoorocoa HH OWWD 


'<* 2 Out of Tolerance 
‘'W' = Weekly 


EQUIPMENT 
AVAILABLE 

8 HOURS/DAY— 
TOTAL = 32 HOURS 


Workcenter labor capacity 


Alternate load measures 


Although labor is often the capacity constraint 
in manufacturing operations, this is not 
always the case. CAPACITY REQUIRE- 
MENTS PLANNING can calculate resource 
requirements both in terms of labor hours and 
one alternate unit of measure (e.g., machine 
hours, cm2, etc.) which can be specified for 
each workstation. Both load measures are 
accumulated and reported separately for each 
workstation, so that they can be analyzed 


HAPPY PEOALER BICYCLE WORKS 
EXCEPTION CAPACITY PROJECTION REPORT 
WORK STATION 


ie) Ww. BW M Q SA A 


UPPER TOLERANCE 115 120 120 125 1 8 150 150 
LOWER TOLERANCE 90 85 85 60 60 60 50 


PLAN SUGG TOTAL CAP CUR CUM 8 
10 2 
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58< 
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4 

9 

9 

8 

8 
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~ 
@OAn Or oun ow 
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Total labor hours 
planned for each 
periad 





°Q' = Quarterly 


Percent by which 
planned load is 
outside of stated 
tolerances 
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LABOR 

AVAILABLE 

8 HOURS/DAY— 
TOTAL = 16 HOURS 





independently of one another or together. This 
capability provides the flexibility to evaluate 
resource requirements in terms most 
appropriate to each individual workstation. 


Load profile reporting 


After all time-phased load profiles have been 
calculated, the resulting resource requirements 
are compared with the standard production 
capacity specified for each workstation. In cases 
where requirements differ from standard 
capacity by more than a user-specified 
percentage, a workstation load report is printed 
which describes the load profile of that 
workstation and indicates the time periods in 
which overload or underload conditions are 
anticipated. 


LABOR --DEVIATION- -------- UTILIZATION OF SCHEDULED CAPACI TY---------- 


50. 100. 150. 
RXXXXXXXXXAARXXARAAAXXAXXXX 
XXXXXXXXXXAAXXXAXAXXAXXKAXXX - 
XXXAXXXXAAXXAKRXXAXAXARKAXAXXAKXAAKK 
XXXXXAARKXXXAAARXXAXARAARAAXAXXKAKAXXXAKRAXAKAKXAX+ 
XRXAXAXXXXXKRAAXXARAAAXXKAXXAXKAXARKAXXAKXXAXX+ 
RRXXKXAXXXXAAKAXARAAXXAXNXXKAAAAXKAKXAXARKAXAKA 
XXXXAXXXXXXXXXXXXXXXXKAXKAAARAKXXAXAXXKAXXXX 
XXXXXAXXXXAXXAXAXXXAKXXKXAXAXARAKAXK 
XXXXXXXXXXXAXXXAXXXXXAXXXXAAXAKAKXXAAKAAKS 
XXXXXXAXAAXAXXKAXAXAXXXXXXXAXXXAXAXX 
XXKXXXAXXXXXAAXXXXAAKXKAXAXKAAAXAXXAAKKAARAXAAK+ 
MRXAXXXXXXXXAXXAXAKRAXXAXXXAAXKAAXXAXKXAXXXAXKXXF 
XXAXXXXXXXXXAKXXXAKAAAKAXXAAXXXXAAAKAARAKAS 


‘SA' = Semiannual '‘A' = Annual 
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Load detail reporting 


In situations where examination of the load 
profile report identifies overload conditions 
which need to be corrected, a load detail 
report can be requested for any individual 


PRINT DATC 
RUN VATE 


04/02/81 15:52 
04/02/81 13:49 


VROTR NETAL 
WKSTU DEUURR 
MANAGER-J. FERGUSON 


7 =-PLERIUOD 


workstation. The load detail report indicates 
the specific work orders which contribute to the 
accumulated load profile during each time 
period, and the amount of workload which 
each represents. 


HAPPY PEDALER BICYCLE WORKS 
DETAIL CAPACITY PROJECTION REPORT 
WORK STATION 


DB UWB M Q SA A 


UPPER TOLERANCE 115 120 120 125 140 150 150 
LOWER TOLERANCE 90 85 


90 60 69 $0 


SCHEDULED DATE- OPER MACHINE- -LABOR 


On the basis of this information, individual 
work orders can be rescheduled into earlier or 
later time periods to arrive at a load profile 
which better fits the available manufacturing 
resources. 
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Using DS3000-1000 with HP/1000 Master Programs 


(ene meh eee See eee aioe EUR GOED SEED SECT TEE) GUD GHD Geen GENS GED SEED CUTS SUES SEED SUED GPRD GaSe cath CuEE SEED Gane COED GiTD Gund ound eadlt GED anmD CUED SHY Gime SOne ohee etme SEED GED Guy EemD ane Gury eomy 


by Joerg Mueller 
SWS SoftWare Systems 
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Introduction 


efficient general purpose computer, which gives 


HP/3000 is a very 


users and programers a lot of flexibility on the software side, Now 


that newer HP/3000 models support HP-IE devices flexibility has been 


extended to the hardware. Nevertheless users would be ill advised to 


use HP/3000 as a measurement data logger or to do any other form of 


of thousands or even 


fast data acquisition. Interrupts at the rate 
only hundreds per second shovild not be sent toa general purpose 
computer. 


Of course Hewlett Packard offers a solution for fast data acquisition 


and processing with the HP/1000 computers. An important additional 


advantage of the HP/1000 systems is a price tag which favourably 


compares to the /3000-line. Users already owning an HP/3000 see the 


disadvantage though of a largely incompatable, different 16 bit 


computer system. Architecture, operating system, language syntax and 


file structure are all different on the two system types. Except for 


trivial cases it is not even possible to define a common Fortran 


subset, so that the same source code could be used on both computers. 


The choice of having both types of systems within one company may 


nevertheless pay off, because a good price to performance ratio can be 


achieved. Once the decision has been made to purchase both HP/3000- 
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and HP/1000-computers it is obviously attractive to link the systems 


with a DS3000-1000 communication line. In fact in certain cases it may 


even be possible to have a memory resident HP/1000 operating system 


without any mass storage of its own thanks to the DS3000-1000 


downloading facility. 


The HP/1000 systems have evolved and this allows to use them also as 


general purpose computers. Nevertheless it is advisable to restrict 


the use of the /1000 and to do most of the programming on the HP/3000, 


if the resources such as the present workload and the communication 


line allow it, because software maintenance on the HP/3000 often is 


easier and has to be done for other applications anyway, so that the 


programer staff usually will be more familiar with the /3000. However 


the environment may impose a more important HP/1000 configuration. 


Some problems with DS3000-1000 which may occur under’ such 


circumstances will here be discussed. Program to program communication 


(PTOP) will be analysed primarily in this paper, but the other forms 


of communication also will be discussed briefly so as to see their 


respective merits. 
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1. Respective merits of the DS3000-1000 features 
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Most of the RTE-IVB operator commands can be issued from a HP/3000 


remote session. It is possible to start and analyse the state of the 


RTE-system. In fact a RTE-IVE memory based system may entirely be 


controlled by a HP/3000 session. The HP/1000 is working as a front end 


computer in such a case, a configuration, which may be very useful. 


It is interesting to note that on the HP/3000 a Cross-Assembler of the 


HP/2100 is available (which in effect allows a subset of the HP/1000 


instructions) and a Cross Loader also exists. A Fortran crosscompiler 


exists in the contributed library now. It therefor now should be 


develop a complete HP/1000 application on the /3000 and 


possible to 
Simply download by DS3000-1000. The HP/1000 does not need to have any 


storage device in such a case. 
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1.2. Remote EXEC calls 


An EXEC call is familiar to all HP/1000 programmers. The HP/3000 


equivalent are the system intrinsic calls. The system resources may 


programatically be used by such calls. Input/Output, program 
scheduling, segment loads and time requests are possible. It is 
therefore feasible for a HP/3000 process to use all HP/1000 
peripherals. Only the actual driver of the device is residing on the 


HP/1000 in such a case. 


The opposite type of calls, i.e. the use of HP/3000 system intrinsics 


by a HP/1000 program, is not possible however. 


1.3. Remote file access 


Although HP/1000 files are not easily accessible by HP/3000 session 


commands, it is however fully possible to use HP/1000 files by a 


HP/3000 program. Such files cannot only be read and written to, but 


they can be created, opened and closed, renamed or also purged. The 


Structure of the files remain of the HP/1000 type of course. 


Besides different file structures the two computer systems also have 


different real number representation. This must be remembered for 


binary files which are commonly used by HP/1000 and HP/3000 programs. 


Except for a little snag in case of a zero the SPL-routines CRIR3 and 


CR3R1 contained in the contributed library allow correct conversion 


between the two types of real variables. 
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possible for a HP/1000 program to access HP/3000 


Again it is not 
files. One obvious problem in this context is the maximum length of a 


name, which may only have up to six characters for a file on the 


HP/1000 instead of 8 letters as on the /3000. 


a 


1.4 Program to Program Communication (PTOP) 


The most powerful communication tool available within DS3000-1000 is 
the PTOP-package. It consists of a set of nearly identical procedures 


available on both computers. 


For a PTOP user application to work a pair of programs must exist. The 
program initiating the communication is the so called master program. 


The other program is called a slave program and is automatically 


scheduled by the respective operating system, when the master program 


initiates the communication. The master program may be on the HP/3000 


or on the HP/1000. Since a HP/3000 program can practically control all 
will not often be necessary to have 


resources of the HP/1000, it 


HP/3000 master programs. Usually the other forms of remote access will 


be sufficient. Whenever a HP/1000 program wants to access the 7/3000 


there is no other choice however than to use PTOP communication. 


The master program initiates communication by the POPEN procedure. The 


slave receives all information by a GET call and returns its 


information by ACCEPT or REJCT. On the master side the following other 


procedures are available: 
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PREAD to receive a buffer of information, 

PWRITCE) to send a buffer of information, 

PCONT (ROL) to exchange a "tag"-field i.e. a buffer of 
20 words, 

PCLOS(E) to abort the slave program, 


PCHECK (/3000) to analyse the last PTOP transaction. 


Although the procedure calls are very simple, PTOP communication can 
present some difficulties to a beginner. Whenever multiple master 
programs initiate the same slave or automatic scheduling is wanted, 


problems may increase even more. But on the other hand applications 
can be tackled, which otherwise could not be realised at all. In fact 
once DS3000 is installed, PTOP can prove to be a very useful tool for 


concurrently running programs within the same computer system. 
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2. SGitvation of CIBA-GEIGY Photochemie (Fribourg, Switzerland) 
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The computer configurations to be discussed here as a practical case 


have the following simplified outline (Fig.1). 
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Fig. 1 
Configuration with hardwired 
connections. 
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The HP3000/II system serves primarily as development system, the 
HP3O000/III supports materials control, production management, quality 
control and distribution and is thereby fully loaded. The HP/1000 
systems perform measurements, control the instruments and process the 
data for Quality Control. The results are intermediately stored on the 


HP/1000 disc and usually daily transmitted to a HP/3000 data base, 


Had the HP/3000 systems not been so heavily loaded, a configuration 
without disc-system could have been envisaged. Since this solution was 
out of the question, the benefits of largely independent HP/1000 
systems were fully exploited. System operation still had to be simple 
though since no actual computer operator could be afforded for the 


/1000-sSystems. 


It is here that local PTOP processing on the HP/1000 systems proved to 
be very useful. Concurrently running programs could thereby easily be 
synchronised. The PTOP programs running with the HP/3000 are not of 


such a nature as shall be shown later. 


The usual contact between the HP1000/45 and the HP3000/III during the 
normal working hours restricts itself to a few occasional 
/3000-sessions initiated on the /1000 or the fetching of a source file 
as will be seen later. The daily evening transmission sends all 
relevant measurement results for complete evaluation and storage to 
the 7/3000. Since the /3000 systems are continuously operator 
controlled this is also the place all plotting is done through batch 


jobs streamed by the transmission program. 


The transmission programs contain .automatic maintenance functions so 


as to eliminate measurement results older than two days on the 
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/1000-disc, if transmission and storage on the /3000 were faultless. 3. DS3000-1000 PTOP programs 
The remaining important function of the DS 3000-1000 line enables to 
set up the HP/1000 master data files from scratch. This is done after For the three types of transmission operation mentionned three pairs 
every disc copy (usually once a month), whenever a new software of PTOP programs had to be written: 
revision is installed and when the master sets are updated on the 
43000 side. The only updating mechanism for those /3000 master sets 1) PUGE: to put or get source files 
allowed to the user go by way of the /1000. Thereby data integrity 
usually is conserved eventhough the information is stored on both 2) PUTSE: to transmit and maintain 
systems. Of course there always will be a hurried smart user ruining | the measurement result files 
the concept. 

3) FMDEN: to maintain the master data sets 
Except for the occasional problems with ignorant new users the system 


has been successfully operational in automatic mode for several months All three applications obviously aim to do programatic remote file 


now. access from the /1000 to the /3000. As it was shown earlier this 
function only can be achieved by PTOP communication. Had the amount of 
initial problems been foreseen it probably would have been more 
economical to sacrifice the requirement of at least semi-automatic 
operation and have the user manually start a /3000 session and a /3000 
program, which then could directly do remote file access without PTOP 
Communication. Now the PTOP pairs are operational they offer easier 


use though. 


3.1. PUGE (PUt and GEt) 


Source file maintenance, i.e. creating back ups and only keeping 
source files, which are being worked on directly on disc, is a 
housekeeping problem common to all computer systems. Having 


DS3000-1000 this problem covld elegantly be solved with some 
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additional benefits. 


The pregramers disc caninidges containing his source files are 
declared a scratch area and are usually entirely erased every week or 
two. Whereas such a way of operating a HP/3000 probably would create a 
programers revolution, the HP/1000 with a DS-link can be maintained in 


such a manner, because 


:RU, PUGE 


+GET source 


will rapidly give the file back (it takes 8 seconds to get the + 
prompt and e.g. 25 seconds for a source file of 300 lines to be 
available on the /1000). Of course eventually the source files are not 
available on line on the /3000 either anymore. In that case the 
programer has to have the source reloaded from mag tape on to the 


73000 and can then fetch it again, obviously a more tedious operation. 


The additional benefit is the ease of maintenance on the HP/1000. A 
procedure using PUGE is all that has to be called, whereby all source 
files are transmitted to the /3000 and there renamed to suit the file 
naming conventions of the /3000 (a source &SOURC.JM will become 
SSOURCJM.HP1000 on the /3000). The whole scratch area then is simply 


purged. 


The program pair to transmit measurement data essentially operates in 


H5 11 


the same manner as PUGE as far as the communication is concerned. One 
of the aparent differences is the automatic streaming of batch 


evaluation jobs by the HP/3000 slave. 


The measurements of a day are usually transmitted within about 15 


“minutes. 


3.3, FMDEN (Fetch Master sets for DENsitometry) 


By this program pair either a complete dump of all relevant master 
sets from the /3000 to the /1000 is realised or individual data is 


updated on both computers simultanously. 


A complete dump takes about one minute and fills 805 sectors of the 
7906 disc. This corresponds to a practical speed of 25 kBaud (in the 


software sense), 


4. Design of PTOP program pairs 
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As a first general rule it can be stated that PTOP communication 
shovld be avoided, whenever other means such as remote file access or 
remote EXEC calls can give the same result, because the application 


Will be operational more rapidly. 


There are situations though, as seen earlier, when PTOP communication 


H5 12 


is the only good solution for the end user. Even between two HP /3000 
such program pairs may be useful as well described in the DS3000 


reference manual. 


Once it has been decided to vse PTOP communication, programing is 
usually done in such ‘a way that the computer initiating the 
communication has the master program and che. other one the slave. 
DS3000-1000 appears to have a bug though and it is currently not 
advisable to write HP/1000 master programs and HP/3000 slaves. Once 
the programs are in working order there are no big problems to be 
expected. Testing proves to be very disagreeable though, because an 
abort of the slave on the /3000 on bounds violation, integer overflow, 
an inexistent file or other such normalities in a testing phase 
systematically provokes a system down of MPE. Obviously the poor 
programer provoking such a small disaster ona production oriented 


heavily loaded HP/3000 will have plenty of niceties to hear. 


If a /3000 slave has to be written there are a few options which 
increase the chance of MPE-survival. An obvious solution is to make 
the slave as short and simple as possible. Delegate more intricate 
work to previously or later executable programs. One of the 
possibilities in this context is the use of streamed subsequent jobs. 
Another solution can consist of a very simple PTOP pair, which only 
initiates the communication and then is followed by another pair, for 
which the master is on the /3000 side. In fact it is possible for a 
slave program itself to become master of another. Probably this would 
not help to solve the abort problem (it has not been texted); because 
it appears to be related to the original, atypical scheduling of the 


slave. 
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Other obvious means of avoiding the slave to abort consist in all the 
necessary tests to intercept the potential error. This requires 
additional code though and thereby makes the testing phase longer. The 
final way out for testing again is disagreeable: night shift. Wait 
until all those backlogged batch jobs are out of the system and then 


learn to warmstart MPE! 


There are other potential problems with PTOP. A programer glancing 
through the available procedure calls intuitively assumes that 
communication starts by POPEN and terminates by PCLOSE. The assumption 
is correct for POPEN, but PCLOSE not only stops communication, but 
also aborts the slave, even if it is concurrently working for another 
master, Except for emergency exits a master program will therefore 


contain at least one POPEN, but usually no PCLOSE. 


A slave must be careful by what process it is called. All transactions 
of the master are received by the GET procedure. By program logic 
maybe a PREAD is expected to be calling, in some cases it may though 
be a POPEN from another master or, in fact, from the same master, 


which terminated and restarted for some reason. 


From all # that has been said it primarily can be concluded that PTOP 
communication should be kept as Simple as possible, especially if the 
programer is inexperienced with DS3000. Hopefully the system down bug 
will be out before MPE revision Zephyr (or whatever) arrives and then 
PTOP communication can be a very useful tool even between a /1000 and 


a /3000. 
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Configuration with hardwired 
connections. 
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PROTOS - A COBOL Procram GENERATOR For He HP3000 
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GLOBAL OPTIMIZATION 


By 


d, Tipton Cove 


Coue & Van Sickie Company, INC.- 


Austin, IX 


( ABSTRACT) 


TITLE: Global Optisization 


SPEAKER: J Tipton Cole, Cole & Van Sickle Coapany, Inc., Austin, TX 
P.O. Box 15085 8900 Shoal Creek 404 Austin, Texas 78761 USA 
ABSTRACT: Global optiaization of any computer application for 
business is facilitated by observing a few basic rules: 1) work 
on the right problen, 2) optimize only where it helps, 3) optinize 
for the total lifetine cost of the project, and 4) use proven 
methods and tools. Technical workers and managers often lose 
sight of business objectives. Worse yet, despite all of the talk 
about software engineering, we neglect fundanental engineering 
principles and techniques. 

This talk stresses the importance of concentrating on the 
business purposes behind the project and the importance of inpleaen- 
ting the applications now rather than later. 


This presentation is designed for DP managers, non-DP managers who 
have responsibility for DP or who aust deal with the DP departnent, 
and DP staff menbers with managerial aspirations. 


HUH 


IF YOU FEEL ASPIRATIONS FOR A COMPLETE TEXT, ASK THE 
AUTHOR - UNTIL NOW THERE IS NONE FOR THE PROCEEDINGS - 
( EpIToR ) *** 
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( ABSTRACT) 


TITLE: PROTOS - A COBOL Program Generator for the HP3000 
SPEAKER: J Tipton Cole, Cole & Van Sickle Conpany, Inc., Austin, TX 


ABSTRACT: PROTOS is a COBOL progran generator written exclusively for 
the HP3000 fanily of computers. It is designed to work naturally and, 
efficiently with IMAGE and ¥/3000. It writes COBOL code that takes 
advantage of the strengths of HP’s best software and of the strengths 
of the HP hardware. The COBOL code follows the best prograanming prac- 
tices. It is easy to read and understand; it is well-structured. In 
fact it is superior to hand written code in quality as well as cost. 

This talk covers the reasons that business organizations 
need tools such as PROTOS, and the benefits that PROTOS brings to any 
business application project. Discussion of specific features and 
denonstration of PROTOS in action are left to the question and answer 
period and individual neetings. 


This presentation is designed for BP managers, nor-DP managers who 
have responsibility for BP or who aust deal with the DP departaent, 
and DP staff nenbers with nanagerial aspirations. 


HREEE 


NOTES SEE ABSTRACT BEFORE (EDITOR) *** 
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TRANSACTION PROCESSOR FOR THE HP3000 
ee ee ee 


I am sure that each of us has had the need to manipulate files, 
Or perform bulk updates of an application database, and found 
that the existing methods are either incomplete (i.e. FCOPY) or 
too troublesome (i.e. COBOL) to use. Most application systems 
involve several standard batch functions which require custom 
programming. Yet the task involved is so standard one should be 
able to specify it in a simple, logical and straight forward 
manner. 


Tnese functions can include: 


Daily, weekly, or monthly rollovers. 
Reformatting a file. 

Producing a summary file. 

Selectively copying based on some condition. 
Copying elements from one file to another. 
Reformatting a database. 


File manipulation tasks are a common requirement in developing 
as well as running most application systems. While excellent 
productivity tools now exist for large segments of application 
development and maintenance, batch processing programs still 
have to be prepared in the same tiresome manner. 


The paper introduces the concept of a powerful batch-oriented 
data manipulation tool called a TRANSACTION PROCESSOR, which 
will keep pace with and interface with current state-of-the-ar- 
productivity tools. | 


The TRANSACTION PROCESSOR will be called QTP and will 
complete Quasar Systems’ family of application generator 
products, which currently include QUIZ for reports and QUICK for 
screen-based input. With this family, users will be able to 
generate entire applications in a consistent easy-to-use style. 


This paper will discuss: 


1. QTP in relation to an application dictionary 
2. Design objectives 

3. QTP in operation (some examples) 

4. QTP in the production environment 

5. Design considerations. 
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TRANSACTION PROCESSOR AND THE APPLICATION DICTIONARY 


Tne transaction processor will be able to operate as an 
independent product in association with Quasar Systems 
application dictionary. In essence, QTP will have two 
components: 


1. QSCHEMA 


The schema processor compiles a description of data files and 
element characteristics including data validation and display 
specifications. The compiled schema functions as an application 
dictionary, providing central administrative control and freeing 
users of QTP from a great deal of repetitive programming. 


2. QTP 
Under the control of specification statements which can be used 
by both programmers and non-programmers, QTP will carry out 


two major functions: | 


.- Standard batch applications 
- file manipulation. 
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DESIGN OBJECTIVES 
The design objectives of QTP are: 


- tO support the standard maintenance functions of add, change 
and delete against all data permanently on file 


- to support standard editing of input including, type 
checking, value range checking, and pattern matching 


- tO support the copying of elements from one file to another 
- to allow the reformatting of files and databases 
- to be able to produce summary files 


- tO Support these summary options: Sum, count, average, 
maximum, minimum, percentage and ratio 


- to be able to specify the sorting and selection of input files 
- tO support any combination of IMAGE, KSAM and MPE files 


- to reference the structure, composition and elements of files 
in a central independent schema 


- to use concise specification statements in simple free-form 
syntax. 
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THE TRANSACTION PROCESSOR IN OPERATION 


TO show the scope of the QTP in operation, here are four short 
examples of situations which occur frequently and which normally 
require specially written programs. 


1. New product number 


Tne manager of inventory control wants to assign a new product 
series "M" to all series "S" product numbers greater than 6000. 
With QTP, this task could be accomplished by entering the 
following statements: 


ACCESS PRODUCTS 
SELECT IF PRODUCT-CONE = "S* AND PROLUCT-NUM * 6000 
FILE FRODUCTS UPDATE 
ITEM PRODUCT-CODE FINAL “M" 
60 


Tne ACCESS statement specifies which file(s) are to be read--in 


this case, the file PRODUCTS. The SELECT statement then 


restricts the selection of records from the product file to 
those records to be changed. The FILE and ITEM statements 
specify the changes to be made to selected records. The GO 
statement causes the QTP request to be executed. 


2. Organizational change 


Tne San Francisco branch has been reorganized and is now part of 
California branch. All reference to San Francisco is to be 
deleted and all records for San Francisco employees are to be 
updated to reflect their new status as records of California 
branch employees. 


ACCESS BRANCHES LINK TO EMPLOYEES LINK TO BILLINGS 
» SELECT IF BRANCH-NO OF BRANCHES = "SF" 
* FILE EMPLOYEES UPDATE 
o ITEM BRANCH-NO FINAL "CA" 
* FILE BILLINGS UPDATE 
ITEM BRANCH-NO FINAL "CA” 
= 60 


Tne ACCESS statement in this example illustrates multi-file 
access. Keyed linkages between files can typically be performed 
automatically, using information in QSCHEMA. The ITEM 
statements in this example set BRANCH-NO to "CA" in the selected 
EMPLOYEES and BILLINGS records. 
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3. Culling obsolete data 


A company wants to streamline their customer file and delete 
anyone on their mailing list who hasn't corresponded for over a 
year. 


ACCESS MAIL-LIST 

SELECT IF 365 = (DAYS (SYSDATE) - DAYS (RESFONCE-DATE)) 
FILE MAIL-LIST DELETE 

GO 


The FILE statement in this example deletes all records of 
MAIL-LIST that nave satisfied the condition in the SELECT 
statement. 


4. Reformatting a file 


QTP will be ideally suited to problems involving the 
reformatting of files. Assume for instance, ‘that the old 
customer file shown in Figure 1 is obsolete. The "PYR-SALES" 
(previous years sales) item is to be dropped; "YTD-SALES" (year 


to date totals) is to be expanded for larger dollar volumes; 
item "CUSTOMER-ID" is to be expanded; an item "SALESMAN-CODE" is 
to be added; and all items are to be re-ordered. 


Figure 1 
OLD CUSTOMER MASTER NEW CUSTOMER MASTER 
CUSTOME R-NAME X (20) CUSTOMER-ID xX(10) 
CUSTOMER-ID X(6) CUSTOME R-NAME X (20 ) 
CUSTOMER-ADDRESS X (60 ) CUSTOME R-ADDRESS X (60 ) 
PYR-SALES 9(6) SAL ESMAN-CODE X(6) 
YTD-SALES 9(6) YTD-SALES 9(10) COMP 


Tne steps needed to format the new customer file are: 


(a) Unload the master file. 


ACCESS CUSTOWER 
SURFILE TMF OUTPUT CUSTOMER 
G0 


(b) Cnange the schema, purge and recreate the customer. file 
(details not shown). 
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(c) Reload the new master file. 


» ACCESS *TMP 
* FILE CUSTOMER ADD 
> 60 


(ad) Purge the temporary file. 
sPURGE TMP 


The SUBFILE statement creates an = ad-hoc file containing 
specified information. Subfiles automatically contain their own 
schema and are therefore self describing. In this example 
SUBFILE creates a temporary file TMP containing a copy of the 
customer master file. 


QTP automatically performs’ the following manipulations’ for 
commonly named items in the two files: 


- changes item type 
. changes item size 
- changes item order. 
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QTP IN THE PRODUCTION ENVIRONMENT 


The following two examples look in detail at how QTP might 
handle two common month-end production situations. 


l. Adding 1% interest to all invoices 
over 30 days due 


To expand on a typical accounts receivable situation, assume a 
company has reached the due date for monthly accounts 
receivable. The account manager wants to add 1% interest to all 
outstanding accounts and update the master file. QTP performs 
this task in fewer than 20 specification lines. 


ACCESS ACCOUNT-MASTER LINK TO ACCOUNT-DETAIL 
SORT ON ACCOUNT-NO, INVOICE-NO 
TEMPORARY INVOICE-DATE RESET AT INVOICE-NO & 
INITIAL DATE OF ACCOUNT-DETAIL & 
IF TYPE OF ACCOUNT-DETAIL="INVOICE” 
TEMPORARY INVOICE-BALANCE RESET AT INVOICE-NO INITIAL 0 
SUM AMOUNT OF ACCOUNT-DETAIL INTO INVOICE-BALANCE & 
IF TYPE OF ACCOUNT-DETAIL = “INVOICE” OR & 
TYPE OF ACCOUNT-DETAIL = "INTEREST" 


nage ae we we we 


oe ae ie 
i 


> SUM AMOUNT OF ACCOUNT-DETAIL INTO INVOICE-BALANCE NEGATIVE & 
> IF TYPE OF ACCOUNT-DETAIL = "PAYMENT" 

> FILE ACCOUNT-DETAIL ALIAS INTEREST ADD AT INVOICE-NO & 

> IF SYSDATE > INVOICE-DATE + 30 

> ITEM AMOUNT FINAL INVOICE-BALANCE * 0.01 

* ITEM TYPE FINAL “INTEREST” 

» FILE ACCOUNT-MASTER UPDATE AT ACCOUNT-NO 

> SUM AMOUNT OF INTEREST INTO BALANCE OF ACCOUNT-MASTER 

» 60 


The account details are accessed and sorted on account number 
and invoice number. 


Two temporary items, INVOICE-DATE and INVOICE-BALANCE are 
created to hold the date and accumulated outstanding balance of 
each invoice. 


Tne two SUM statements accumulate the outstanding balance. 
The first FILE statement together with the following two 
ITEM statements create a new detail record for the interest if 


the invoice is past due. 


The last FILE statement and following SUM statement update 
the account balance to reflect the new interest change. 
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2. Standard Batched Update 


Tne standard batch update is probably the most universal QTP 
application. At the end of each day, a company wants to total 
all money received and prepare for the next day's transactions. 
With QTP, this assignment could bc performed in ten 
specification lines. 


ACCESS BATCH-HEADER LINK TO TRANS 

SELECT IF TOTAL-ENTERED = TOTAL-CALCULATED 

SORT ON ACCOUNT-NO 

FILE ACCOUNT-DETAIL ADD 

ITEM TYPE INITIAL "PAYMENT" 

FILE ACCOUNT-HASTER UPDATE AT ACCOUNT-NO 
=» SUM AMOUNT OF TRANS INTO BALANCE OF ACCOUNT-MASTER 
~ FILE BATCH-HEADER DELETE 
» FILE TRANS DELETE 
» 60 


a 


The ACCESS, SELECT and SORT sta’ements retrieve transactions 
from balanced batches and sort them by account number. 


The FILE statement for ACCOUNT-DETAIL creates payment records 
from the transactions. ; 


Tne FILE statement together with the following SUM statement 
update ACCOUNT-DETAIL to reflect the new payments. 


The final two FILE statements delete all processed batches and 
transactions. : 
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TRANSACTION PROCESSOR STATEMENTS 


Tne major specification statements used in QTP will be as 
follows: 


ACCESS specifies the files to be read, the order in 
which they should be read and linkage between 
files. 

BUILD takes all requests defined up to the BUILD 
statement and saves these requests into a named 
MPE file for future use. 

CHOOSE specifies an explicit set of data by key for 
retrieval. 

DEFINE used to define a frequently used expression. 

EDIT specifies that input files be edited according to 
editing defined in QSCHEMA. 

FILE defines an output action to be performed on a 
file. These actions are: 

ADD add if record does not exist 

UPDATE add if record does not exist, else replace 
REPLACE replace if record exists 

DELETE delete if record exists. 

ITEM indicates specific items to be assigned initial 
or final values, or to accumulate totals. 

RESET resets status control options to original status. 

SELECT restricts selection of records for processing to 
those which satisfy a condition. 

SORT specifies the order in which records are sorted. 

SUBFILE creates a sequential file (MPE). 
Does not require the file to exist in the QSCHEMA. 
Will produce its own schema information in the 
header of the file, and be accessible to both 
QTP and QUIZ. 

TEMPORARY creates a temporary-item which does not exist in 


the database. 
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DESIGN CONSIDERATIONS 
ENG 


To arrive at a smoothly functioning product, certain design 
considerations were uppermost in the thoughts of the development 
team. 


- Tne desirability of a specification based language to 
insulate users from procedural constructs. 


- The need to support complicated production runs as well as 
ad-hoc file maintenance functions. 


- The need for efficient run time performance. Since QTP 
will run repetitively against bulk volumes of data, its 
design will differ Significantly from a data entry system 
which requires a high degree of user interaction. 


- The need for effective interaction with QUICK to allow 
class data changes in conjunction with data entry. 


- The automatic insulation of users from migrating secondary 


and other file positioning problems inherent in IMAGE and 
KSAM file updates. 
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SUMMARY 


Application systems on the HP3000 are typically composed of 
numerous data entry screens, numerous reports and a relatively 
small number of batch processes which run on a regular basis at 
day-end, month-end and year-end. Significant progress has been 
made towards eliminating the need to custom program data entry 
and reporting functions. Very little attention has been paid to 
the development of productivity tools to perform standard batch 
processing functions. The transaction processor is designed to 
perform most standard batch Operations as well as a wide range 
Of file manipulation’ functions. QTP, together with its 
companion products QUIZ, QUICK, and QSCHEMA, will form a 
complete application generator for the HP3000. Complete systems 
can be built using these components with major savings in 
programmer resources applied to development and maintenance, and 
with real gains in data integrity, system consistency and 
flexibility. 
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lmtrodmetiiom 







The Herbert Seitz Company is ... 





C> A REALTIME DATAPROCESSING SERVICE BUREAU 
Cc) AND SOFTWAREHOUSE 
C> AND HEWLETT PACKARD OEM 












with (1981) .. 






[> 7 own HP 3000 (series 111 AND 44) 
IN OUR BREMEN AND PFORZHEIM BRANCH 











Bremen 


C> AND 10 HP 3000 series 111 IN 
ASSOCIATED COMPANIES 








WITH APPROX, 350 TERMINALS SPREAD 
OVER GERMANY CONNECTED VIA HARD- 
WIRED LEASED LINES/DIALED LINES 










*$ Pforzheim 










o own Computers 





e Associated Companies 





Introduction x 
Se a 





WE PROVIDE OUR SERVICES IN GERMANY AND FRANCE FOR COMMERCIAL 
APPLICATIONS LIKE .., 






=) ACCOUNTING 






za) PAYROLL 


=) MATERIAL MANAGEMENT 







=) SHOP FLOOR CONTROL, 
CAPACITY PLANNING 










=~ TOOLS FOR HP 3000 
OPERATION. SOFTWARE-DESIGN 
AND DOCUMENTATION 







OUR USERS ARE .,., 







=> WORKMEN 
=> DATA TYPISTS, CLERKS 
=> MANAGERS 







ONLY A FEW OF THEM ,,. 






> ARE SPEAKING (HP-) ENGLISH 
> HAVE DP EXPERIENCE 
y+» HAVE SEEN ANY TERMINAL BEFORE 
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THIS PRESENTATION IS A GENERAL DESCRIPTION OF SOME 
TECHNIQUES OF INTEGRATED DATA- AND TEXTPROCESSING ON 
HP3000 COMPUTERS AS THEY ARE IMPLEMENTED IN 1DT3000. 
THIS IS NOT A COMPLETE PRODUCT OVERVIEW. 


1DT3000 1S A DATA~ AND TEXTPROCESSING SOFTWARE PACKAGE 
DESIGNED BY HERBERT SEITZ kG WITH: 


AN IMAGE TEXTDATABASE AND DIC, IONARY 


POWERFUL TEXTEDITING AND FORMATTING FEATURES 
FOR BUSINESS LETTERS AND REPORTS 


FILE ACCESS TO IMAGE-, KSAM- AND MPE-FILES 


A SELF LEARNING DICTIONARY AND AN ON-LINE 
CORRECTION AID 


MULTILINGUAL SCREENS, MESSAGES AND HYPHENATION 
ALGORITHMS 


A CUSTOMIZER FOR CHARACTER SETS, TERMINAL- AND 
PRINTERTYPES, DATAFILES, DATADEF:iNITIONS AND 
OPERATING ENVIRONMENTS 


INTERFACES TO DATAPROCESSING AND DATACOMMUNI - 
CATION 


A DAILY REPORT OF THE OUTGOING LETTERS AND RE- 
PORTS 


A TRACKING MECHANISM FOR RLWEWED SUBMISSIONS 


A BATCH PROCESSING INTERFACE 
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GENERAL CONSIDERATIONS: 


IDT 


THE USE OF A DICTIONARY MAKES ONLY SENSE IF THE 
VOCABULARY IS SUFFICIENT 


A VOCABULARY OF APPROXIMATELY 150.000 worps Is A 
REASONABLE COMPROMISE (VOCABULARY. DISC SPACE AND 
ACCESS TIME) 


A STATISTICAL EVALUATION OF THE VOCABULARY DURING 
THE SELECTION-PROCESS IS ADVISABLE 


THE GENERAL RULE OF THUMB FOR DATABASE CAPACITIES 
SHOULD BE KEPT IN MIND IN ORDER TO GAIN REASONABLE 
RESPONSE TIME (1.E. CHECKING OF 100 worps IN 2 - 3 
SECS.) 


UNTIL THERE ARE BETTER ALGORITHMS AVAILABLE FOR 


PARSINS, INTERPRETING AND UNDERSTANDING TEXT IN HIS 
CONTEXT IT IS NECESSARY TO MAKE THE DICTIONARY 


=> USER ACCESSIBLE 
AND 


=> SELF LEARNING 


SEE NEXT PAGES 
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CORRECTION AID / DICTIONARY (3) | 


Form 2. Maintenance correction aid 


- — ee 


‘] (1) Vocabulary into correction aid from ‘text name’ | car (A) 
( | 7 


2) Only from section: see 
B’ 


hyphenation exceptions TT 700! 


(3) Print correction aid totally Printer No. :] 
(4) Print hyphenation exceptions totally : 


(5) Vocabulary from MPE-file 
into correction aid 

(6) Yocabulary from MPE-file 
into hyphenation exceptions file 


(7) Copy correction aid into MPE-file 
(8) Copy hyphenation exceptions into MFE-file 


Please enter required activity and press ENTER Fo] 


NEW VOCABULARY MAY BE ENTERED FROM THE TEXTDATABASE (A) OR ONLY SOME SECTIONS 


- OR MPE-FILES ©). IF THE TEXT IS CAREFULLY CHECKED IN THE FIRST PERIOD OF USE THE 


DICTIONARY WIL. BECOME MORE AND MORE SUFFICIENT FOR THE SPECIFIC APPLICATION. THE 
DICTIONARY MAY BE RESTORED TO MPE FILES () FOR BACKUP PURPOSES OR STATISTICAL 
EVALUATIONS, 


word ° 3M 
LZ 


userfriendliness  _ fee eee Rene eek ed 


—_— 


‘a (X) Copy display to printer 


Please enter new word for Your dictionary ' 


THE USER MAY ENTER OR UPDATE DICTIONARY ENTRIES WHENEVER NECESSARY (A). 
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Maintenance of hyphenation-excerptions (DT 3000 


Word 
Hyphenation at 


(*) Normal hyphenation after this column 
(K) for ck to k-k hyphenation (special feature for german) 
(V) for consonant duplication (specia! feature for german) 


existing definitions will be displayed 


[} (X) Copy screen to Lineprinter 


ease mark where You want a hyphenation —__ hen J Sie ole ee opty cell 





THE USER MAY ENTER OR ALTER EXCEPTIONS FOR THE HYPHENATION ALGORITHM (A) WHEN 
NECESSARY. IN THIS WAY THE STANDARD PRECISION OF APPROX, 95% MAY BE INCREASED > 99% 
FOR A SPECIFIC APPLICATION WITH ITS TYPICAL SET OF VOCABULARY AND SIZES OF THE 
FORMATTED TEXT, 
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Form 14300 Te te an ten anee TST 300d 
Text name [CURRDEMG SectionAl ] Password [ Text-File 


f} <1) text entry (4) insert at 


= (5) modify from 
B) 2) print on (6) display from line a 
printer Oj (7) delete all, or from fine _ 
(3) renumber (9) duplicate line 
p> (9) search pattern __. 
y ‘X) Correction aid (0) copy speek) eh 
1 ; 11 : ai ‘ 31 ; 4] , 


«Start* 
Thig 15 an Exampel tior 
wards not fornntained in the MPiktionarg are disp!ayed in inverse 


video and the user 15 atked to check this words. 





ee ee ?. Saas —— 
Please check your text and correct errors ty 


THE CORRECTION AID CAN BE ENABLED THROUGH THE USER (A) AND WORKS DURING TEXTENTRY 
OR UPDATE @). UNKNOWN (NOT NECESSARY WRONG) WORDS ARE MARKED © AND THE USER IS 
PROMPTED FOR RECHECKING AND CORRECTING ©). 


cl $i 


( 71 :a9Wd SM ZLIGS LYIGYdH WNYLNAZNAHOAY LOI 





S39Vd LXAN SA tdWVXA Ads 


SSIYVNOTLIIC vivd VIA Ss302v viva 
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FILEACCESS (3) 


Form 5 Customizing data access (adress-file and master-file 2) IQT 3000 


A (A) Customizing adress-Ffile (B) Customizing master-file 2 


In this form You may customize Your Adress- file 


You will have to describe each field «(1 - 50). 
Existing descriptions will be shoun. 


Field Fieldname alert patent Size(2) Format(3) (F) 
ol. ype 


3@) = om] O eg [arene a Cae 


(1) P4-P12 packed numeric ite (3) ‘X' place for |! alphanumeric 
C2-C10 binary coded numeric item character 
F alpha-numeric item ‘Z" supress zeros 


(2) Size ;: the last digit must be 
you may need one digit for a an 'X’ for a Sign 
sign character! character (numeric-Iten 


(X) Copy screen to Jineprinter 
ease enter tie ormat ! 7 ae ee ee ee eel 


up To 100 FIELDS PER USER AND/OR SESSION CAN BE CONFIGURED (A). THE NAME (B), 
PosiTIoN (C), DATA TYPE (D), size (E) AND OPTIONAL EDIT MASKS CAN BE 
DEFINED AND MODIFIED WHEN NECESSARY, 





FILEACCESS (2) 


Form2s“(wr”TTCCCUCF Te Configuration IDT 3009 


Specification of Address-File: Filename RDSTAN St CtC“‘“‘C(‘C;C;C*@ds 


Filetype a 
f}| <1) IMAGE-DB ADRSTA ] Password ACR 


Searchitem ADRNR. | ‘Detail Dataset) 
(2) KSAM-File (Access via Primary-Key? 
(A) «3 MPE-File (sequential. only for Serial Letters) 


(49 Adress-File not used 


Specification of the Prder |} File : Filename [STIDT  ———s—i“‘(<‘é‘#r”»llY'TT .—~“‘(aCs’C;ésC 


Filetype 
a IMAGE-DB PRODO! ~___}] Password 
Searchitem UDINK (Detai! Dataser) 
KSAM-File (Access via Primary-Key) 

Second Master-File not used 





Copy screen to lineprinter 


THE USER MAY DEFINE OR CHANGE FILENAME AND TYPE FOR AN ADDRESSFILE (A) AND 
ANOTHER USER SELECTABLE FILE (8). 
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~ 
> 
Q 
TW 


St 


FILEACCESS (6) 


Form 4 “(”st”t”~*~“‘SS &WBsSorresstetters . eee 1) ei) 


Text name [J Section [ —] Password [ 


-} (1) From unformatted text or (2) formatted file to printer No. [] 


A letter to addressee: ee ee eee oe ene eee ee. 
without accessing tne addrese-tile 
A letter to all addresses of the addross-file 
Unly selected addresses with field __ 
field __ 


a a nw ww oe ee = Oe 


Using letterhead: dated tor ron submission 5 __ 


With data of tUrder - Master-tile of ep tind ed act BND oS cea 
(X) Margin alignment — Column Conly printer 2h01) 


Your sign Your letter Our sian Date 


: ter the required processing/selection options and press “ENTER- To 


THE FILEACCESS (AND THE DATA SELECTION) CAN BE DONE DURING THE PRINTING / 
SELECTING OF BUSINESS LETTERS (A). DATA MAY BE SELECTED AND INSERTED FROM 
THE ADDRESSFILE (B) AS WELL AS FROM THE MASTER FILE 2 ((). 





FILEACCESS (& 


eahsteioss aoe ean UO 


Text name emoberi] Section AT |] Fascweord {| 


TY} €1) Formatting text (text file -> formatted text file) Columns 
(2) Print formatted text an printer No, 


(X> Insert addrecsee at 


(X) Add from master-file2 Orders 
from 


(X) Blockformat required 


Sear Sre ney Cees ae RUG in Oo tos ae ene eA et ee RT CG Cea a OA 
Flaese enter the required options and press -ENTER- ! 


WiGNee See es 


THE FILEACCESS (AND THE DATA SELECTION) CAN BE DONE DURING THE TEXT FORMATTING (A). 
DATA MAY BE SELECTED AND INSERTED FROM THE ADDRESSFILE AS WELL AS FROM THE 
MASTER FILE 2 €), 
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DATA SELECTION (2) 


Your sign Your Jetter Our sign 


Please enter the required processing/selection options and press -ENTER- ' | 


Password [| 
(1) From unformatted text or (2) formatted file toa printer No. 


(1) A letter to addressee: 1000008 X 

(2) without accessing the address 

(3) A Jetter to all addresses of the address- File” 

(4) Only selected addresses with field _ = 
[| field _ 


(X) Using letterhead: std dated for renewed submission : 020381 


—- 


(X) With data of Order - Master-file of 935-001/21C_ 
(X) Margin alignment — Column only printer 2601) 


Date 
o> ral bs ho 0 re 


MO tm re oe ee ee ee ee en ee eee 


THE SELECTION OF DATA CAN BE DONE IN THE TEXT FORMATTING MODULE OR DURING THE 
PRINTING OF SELECTED BUSINESS LETTERS (A) WITH DATA ELEMENTS OF THE SPECIFIED 
ITEMS + ©. 


SELECTION (1) 


DATA 


W 
ud 
O 
< 
a 
= 
x< 
uJ 
Z 
Ww 
ud 
at 
oO 
= 
< 
x 
uJ 
WW 
tu 
wn 


INQUIRY LANGUAGES AND/OR 


THROUGH LOGICAL COMPARE COMMANDS DURING THE 
BUSINESS _ETTER PRINTING (SELECTED LETTERS) 
REPORT GENERATORS (QUERY. REPORT3000, Ask, 
QUIZ, QUICK, GENEASYS ETC.) PROVIDING THE 
SELECTED DATA IN A IDT3000 BATCH INTERFACE 
THROUGH BATCH- OR SESSION MODE APPLICATION 
PROGRAMS PROVIDING THE SELECTED DATA IN AN 
1DT3000 BATCH INTERFACE FILE 


THROUGH DATA(BASE) 


THE SELECTION OF DATA OUT OF THE ABOVE MENTIONED DATA FILES 


CAN BE DONE IN THE FOLLOWING WAYS 


RECHENZENTRUM HERBERT SEITZ KG 
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La 


2) 
x 
2} 
za 
N 
tr) 
vA 
3 
ys) 
Cc 
= 
>) 
g 
t) 
a 
ar 
es) 
i) 
Lan 
ar | 
N 
a 
Q) 
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4°) 
» 
2) 
89) 


61 


CUSTOMIZER (1) 


Customizer for Hardwareconfiguretion iDt 3000 


IT/UK =6(€2) Deutsch ISU? (3) Francais (4) tspano! 


ASC 
Engligh (2) Deutsch (3) Francais (4) Espanol 


(1) 
anguage 2 C1) 


X) Auditfile eS) addressee in field No. '4O) 
(X) Database for Hyphenation-Exceptions used 
(X) Correction-fiid °°) 


Printer Type Device-Class Printer Type Device-Class 
P2 Z 


(A) Terminal-Printer (B) Lineprinter 2614/2617/2614 
(C) Matrixprinter 2608/2631 as Hardcapy (D) as Device 
(—) Daisywheelprinter 2601 as Hardcopy (F) as Device 
(G) Laserprinter 2680 
(H) Olympia ESW100RO as Hardcopy 
[]} «X) Copy screen to tineprinter 


Piease enter data and prees “ENTER 7 


nae wee wwe = ee ee ee ee + meee meee 8 ee eee em ee ee ee 8 ee + oe ee ee oe ee ee ee eee 


THE INTEGRATION OF DATA- AND TEXTPROCESSING REQUIRES THE OPTION OF TEXTPROCESSING 
WITHIN THE EXISTING DATAPROCESSING (HARDWARE-) ENVIRONMENT (A) INCLUDING CHARACTER 


sets (8), cancuaces (©), DATA Layouts (D) AND THE PROCESSING ENVIRONMENT ©) + © 


DATA SELECTION (3) 


Fora 183 0 Te xe tm ai nt enanee UT 30g 
Text name PEMDBERY Sectionfi2 | Passyord [ Text-File 
oct) text entry (4) Insert at 
(S) modify from 
(2) print on (6) display from Jine [ 
printer 0 (7) delete all, or From line. __ to 
(3) renumber (8) duplicate line ae. ee to 
(9) search pattern Frm 
_ ©) Korrektur (9) copy ee eee ee eee to [| 
| : 11 ‘ 2\ 31 ; 4] ; 51 ; bl. 7} 


Start*™ ae ee enews 
hiss ig an Bancle of IDT300's dataineertion feature. 
e Ex 








trank You for Your letter and Your interest in our new &4B41. The 
price of &4B35 {is very attractive. chu 
Cur local representative Mr. &DSALESMAN will contact You within the 

next few days and provide further informations for You. 


Sincerly YoursSRS$R&VsignerSRaVtitle 





VATA ELEMENTS CAN BE DEFINED BY 1DT3000 INTERNAL FIELD NUMBERS (REFERRING TO 
THE CUSTOMIZED FILE-ENVIRONMENT) OR BY DATA ELEMENT NAMES OF A DATA DICTIONARY 
(picTronary 3000). 
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A DISTRIBUTED COMPUTER SYSTEM INTERCONNECTING HP3000. 


HP 1000 AND OTHER MINI - COMPUTERS 


ByOrn DREHER. HANS VON DER SCHMITT. RAIMOND SCHOECK 


Institut FUR KERNPHYSIK DER UNtversiTAT D-6500 Mainz 


West GERMANY 


A_Distributed Computer System Interconnecting HP3000, HP1000, 
and other Mini-Computers 


Bjorn Dreher, Hans von der Schmitt, Raymond Schoeck 
Institut fiir Kernphysik der Universitat 
D-6500 Mainz, West—Germany 


1. Introduction and early history 


The Institut fiir Kernphysik der Johannes Gutenberg-Universitat at 
Mainz, West-Germany, is a medium size institute for basic research in 
the field of Nuclear Physics. We have an 340 MeV linear accelerator 
for electrons to perform research in the nuclear structure area using 
electromagnetic interaction. Currently an 175 MeV two stage c.w. race-— 
track microtron for electrons is under construction, which is con- 
trolled and operated with the help of two HP1000 computers. The first 
of the two stages is operational since 1979. 


Until 1976 the control of experiments and the data acquisition was 
performed by a (today still operational) CDC1700 "“minicomputer". In 
addition a substantial part of the data analysis was also done on this 
system. By that time we noticed that the computing power and the tools 
for program development of the CDC1700 were no longer adequate for our 
tasks. Therefore we decided to purchase a new powerful minicomputer 
system (HP3000) for the data analysis part of the work and to connect 
to it several smaller systems (HP1000) as front-ends for the real-time 
applications. 


Since at that time the cost for disc memories was higher than today 
and memory-resident operating systems were still around, we wanted to 
be able to perform the program development to a large extent on the 
HP3000, even for the front-ends. Operating systems were to be genera-— 
ted on the HP3000 and then downloaded to the small system. 


In addition, to reduce tne cost for the front-ends, these should be 
equipped only with experiment related peripherals, such as CAMAC 
interfaces, and not necessarily with expensive magnetic tape trans- 
ports or line printers. A concentration of those devices at the HP3000 
would promise a much higher utilization and availability to all front- 
end computers. 
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At that time DS3000/DS1000 was not yet available, but HP had available 
a product called "Programmable Controller", which was an HP2100 (or at 
that time already an HP21MX) computer connected to the HP3000 via a 
16-bit parallel link using Universal Interfaces at both ends. With 
this product came cross software that enabled the user to generate 
RTE-C operating systems, to assemble HP1000 Assembler programs, bring 
it into an absolute form uSing a Cross Loader (XL2100) and download it 
to the front-end computer. There existed also an (unsupported) Cross 
FORTRAN compiler that was compatible with those days' FTN-IV compiler 
of RTE-III. Our final configuration is shown in figure 1. The two 
interconnected HP1000 systems are today running RTE-IV operating 
systems, the third one used to work with RTE-C and we are currently in 
the process of rewriting our applications to be compatible with 
RTE-IV. For the CDC1700 we built an interface to let it appear to the 
HP3000 like an HP1000 computer, so that we could connect it to a third 
Universal Interface card. 


Microtron Experiments 
| | | | 
| | | I 


$————----—+ $------ = + +--------- + +---------+ 
| | | | | | | | 
| HP1000 |====| HP1000 | | HP1000 | | CDC1700 | 
| | | | | | | | 
+—-——--—-~—+ $—-------— + +--------- + +--------- + 
| | ! 
\ | / 
\ | / 
\ | / 
\ | / 
\ | / 
4$—-—-—-——-—---- = --- = - + 
| \ 
| HP3000 | 
| | 
$+----—--------------------- + 


Fig. 1: Overview of our distributed computer system (the CDC1700 
will be replaced by a PE3220 system). 


There existed already some communications software for a similar, but 
in some essential points different, distributed system at the Techni- 
cal University in Berlin. This had been written jointly by HP 
Frankfurt and the Technical University of Berlin. It was kindly made 
available to us and constituted the basis for our current communi- 
cations system between the front-end computers and the HP3000. 
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2. The current system 


In the process of getting the initial system running it turned out 
that both communication drivers in the HP3000 (IOREMO) and in the 
HP1000 (DVR63) were not suited for our problem. Therefore we had to 
modify both, especially the HP1000 side. Now the communication between 
the two computers is really interrupt driven on both sides without the 
need to loop on a status request to see whether the other side is 
willing to send, to receive, or to do nothing at all. 


Today three computers are connected in a star configuration to the 
HP3000 and a forth one will be added in the near future. The peri- 
Pherals of the HP3000 are accessible to the small computers through 
the file system or directly via special communication drivers in the 
HP1000 in the case of magnetic tape units, line printer, and plotter. 
Direct program to program communication between a program on the 
HP1000 and one on the HP3000 is also available. 


In the following we give an overview about the possibilities a user on 
one of the front-end computers has in the current system: 


a. Access to the entire file system of the HP3000 
- Read and write sequentially or in direct access 


- Position to records, write filemarks, space filemarks, rewind, 
etc. 


- Obtain the status of a device 


A supervisory program in the HP3000 (CENTRAL) keeps track of all 
files opened by programs in the front-end computers. so that only 
those programs in the front-end computers may access the files who 
“own” it. When a program closes the connection to the HP3000, all 
files opened by it are automatically closed. In addition there is 
the option to open files globally, so that they can be accessed by 
more than one program simultaneously. 


b. Initiate batch jobs 
c. Create and activate processes 


qd. Program to program communication between programs in the front-end 
computer and programs in the HP3000. 
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e. Perform MPE commands 


f. Generate an RTE-C operating system on the HP3000 and download it 
into the target machine. Develop application software in 
FPORTRAN-IV or HP1000 Assembler, bind it into the target system and 
Gownload it dynamically into the target machine. 


g. Transparent use of peripherals of the HP3000. Magnetic tape units 
and the lineprinter are accessible from the front-end processors 
as if they were connected directly to them, e.g. through FORTRAN 
READ/WRITE statements or EXEC-calls. The plotter is available 
through standard (Calcomp-) calls. This concept is easily expanded 
to other peripherals. 


According to the initial demands to the system, communication is 
normally initiated by one of the front-end computers. Each request 
consists of a pair of messages of variable length. The first message 
contains the request type and the necessary data. The second (return) 
message contains possible error codes and the resulting data. The 
interface on the HP1000 side is a set of subroutines (SATTL) that 
allow the programmatic execution of all features mentioned above, or a 
direct EXEC call to the drivers of the (virtual) peripheral devices 
attached to the HP3000. An interactive program (KOPPL) allows to exer- 
cise all requests to the HP3000 and to transfer files from one machine 
to the other. 


The receiving process in the HP3000 is one program (CENTRAL), which 
performs all necessary operations to satisfy the individual requests. 
This process runs.as an always present batch job (in the CS queue), 
one job per link to a front-end computer. Each front-end computer can 
have up to 5 programs communicating with the HP3000 at the same time, 
each of which may have up to 10 files simultaneously open. Those 
numbers are more or less arbitrarily chosen and can be easily 
increased when the need arises. Requests from different programs can 
be freely intermixed. 


3. Need for additional functions 


As one can see from the previous chapter, the current system con- 
stitutes a fixed master/silave relationship between two communicating 
computers, where the front-end processor is the master and the HP3000 
is always the slave. This was satisfying for the first few appli- 
cations, but soon it turned out that a dynamic establishment of the 
master/slave relationship and a more direct communication between 
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programs/processes in the various machines would make many appli- 
cations easier to implement. In particular, it should be possible to 
start an exchange of messages from any computer. 


A general process to process communication across the entire distri- 
buted system seemed to be the most attractive solution. Of course, the 
existing higher-level functions of our current system should not be 
touched. 


4. The HP1000 message system 


Fortunately a system that fulfilled many of those needs had been 
implemented in 1978/79. It was developed in our institute for the 
inter-process communication (IPC) among the various on-line control 
programs which are distributed within the two HP1000 computers that 
control the new microtron mentioned in chapter 1. 


The communications protocol of the process-to-process layer is based 
on the exchange of messages via just two operations: SEND and RECEIVE. 
Messages have the same form whether beeing exchanged locally in one 
computer or between the two computers. The participants of the conm- 
munication are addressed by 10-bytes symbolic names. These are mapped 
to target computer and process by the system. 


Messages are transmitted as sequences of fixed-length packets ina 
store-and-foreward fashion. Each packet is 64 bytes long consisting of 
a header (essentially sender and receiver addresses) and the data. The 
packet transmission constitutes the computer-to-computer protocol, 
which is thus very simple and easy to standardize. 


In addition, I/O requests to devices attached to remote computers are 
transparently handled by using IPC between I/O drivers. 


In summary, this message system enabled us to build a modular distri- 
buted control system. The modules (programs) are explicitly portable 
between the two computers by using the symbolic addressing scheme and 
by the transparent I/O system. Thus programs can be freely redistri- 
buted on demand ina growing system, as our microtron control system 


is. 
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5. The second generation communications system 


Based on these ideas, we are currently in the process of implementing 
a second generation of our communications system uniformly throughout 
our distributed system. It will interconnect one HP3000 with three 
HP1000's and one PE3220 computer. 


The new system will also be an IPC system transmitting messages decom- 
positioned into packets. However as compared to the above application, 
the system must be capable of higher data flows since the number of 
data bytes per message will be larger on the average. Therefore the 
packet size will be increased to 128 bytes. On the other side there is 
less need for a fully symbolic addressing capability and other over- 
head-generating features of the HP1000 message system. Thus a higher 
data throughput may be achieved. Some essential features of the new 
system will be given below. 


From an architectural viewpoint, messages between two processes will 
be transmitted in our system by a store-and-foreward packet switching 
mechanism. 


Splitting messages into a number of smaller packets has important 
advantages: 


a. Long messages do not necessarily monopolize a communication line. 
They can be interleaved with packets from other (more urgent ) 
messages. 


b. By using fixed length packets as the vehicle of message transfer, 
it is easy to buffer messages prior to the actual transmission and 
incoming messages before they are collected by their recipient. 
Buffering space will be taken from a global packet pool common for 
all ports of a particular computer. 


c. Buffering separates nicely the lower communications layer, that 
controls just the traffic of incoming and outgoing packets, from 
the next higher layer, that consists essentially of the decom— 
position of messages into a series of packets (SEND operation), 
the reconstruction of messages from a series of packets (RECEIVE 
operation), and the mapping of symbolic addresses. 


d. W store-and-foreward capability comes as a by-product from the 
buffering. 
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Besides packeting/de-packeting, packet transmission, and buffer 
management, the system has to perform additional monitor functions on 
the participating processes. 


i. Processes must be suspended and re-activated in the course of 
SEND and RECEIVE requests. 


ii. Time-out conditions may arise in RECEIVE as well as in SEND 
requests; the former when an expected message is not received in 
time, the latter when a transmitted message is not consumed by 
the recipient in time. 


From the hardware point of view we will still have point-to-point con- 
nections between the various computers in a star configuration (with 
the exception that two HP1000 Systems are connected directly with each 
other), the HP3000 being the inner node. we will use the existing 
hardware (16 bit parallel plus some control lines) with Universal 
Interfaces in the HP-computers on both sides. However, as can be seen 
from point c above, the kind of hardware is not that important for the 
designed function of the whole systen. 


6. Implementation 


To reduce programming time and to improve maintainability and 
documentation of the system as well as portability we decided to write 
as many as possible routines in a high-level language. Por the 
non-HP3000 systems we decided to use RATFOR {1], which is a FORTRAN 
dialect that adds structured elements to FORTRAN-IV. The output of the 
RATFOR preprocessor is standard FORTRAN-IV, which serves for the 
portability of RATFOR programs. Only few routines on the HP1O00 
systems are written in HP1000 Assembler. 


The same approach will be taken for the PE3220 system, which will 
replace the CDC1700 computer. 


Since it is expected that the HP3000 will have the highest message 
traffic of all computers and since several routines have to perform 
their tasks in privileged mode, we decided to write the HP3000 side in 
SPL, at least the inner kernel with the most time-critical parts of 
the system. This allows us to make the best use of the HP3000 archi- 
tecture and its instruction set, thus lowering the time overhead 
introduced by the packet switching architecture. 
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7. Conclusion 


In summary, even the current (first generation) system and the 
dedicated HP1000 message system have proved very valuable in many 
daily applications. The second generation system, that will be avail- 
able on all our in-house (mini-)computer systems, will have an even 
higher impact on many current and future applications. After 4 years 
of experience with an own, custom designed, communications system, we 
feel that in our case this was the right way to go. Even today, there 
is no communications sytem commercially available that would fulfill 
exactly all our needs. Having all the knowledge about the system in 
house allows us quite easily to add new required function to the 
system, as they arise. The fact that most modules of the system are 
written in a high-level portable language makes it easy to put the 
system on other computer families and integrate them into our distri- 


buted system. 


(1] B.-W. Kernighan, P.J. Plauger: Software Tools, Addison-Wesley 
Publishing Co. 1976 
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THE USE OF EDP IN THE FREIGHT FORWARDING 
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Presentation Abstract 


Presentation Title: . EDP i he freight forwarding and ships aqgenc 


business 








Author(s): Hardy Jensen, Jergen Rix 


Title(s): Sales Manager, Sales Director 


Address: Data Advice A/S, Niels Bohrs Vej 3, DK-6000 Kolding 





Abstract: (No more than 200 words) 


Data Advice A/S, is an OEM- and software house in Denmark, which have 


specialized in the freight forwarding and ships agency business. 


forwarding and ships agency package for use on HP3000 machines. 


In this package Data Advice A/S have integrated the forwarding and the 
book-keeping procedures so that double data registration has been 

avoid, also is the system build so, that is uses the advantage of an on-line 
machine i.e. information typed in by one person is at once accessible to 
all_users of the system. 
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Abstract: (No more than 200 words) aT 
DATA ADVICE? ““ o 


Briefhy the system, among other things, contents of following functions: 


- Import and export routines from the point where the order is taken 
through part-/full-load bookings, way-bill handling, haulage plan- 
ning, loading Tists, unloading lists, manifesting, customs 
clearance (both import and export), automatic invoicing to total. 


financial accounting including book-keeping on all relevant accounts. 
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NEW SOFTWARE ENG,{NEERING ALTERNATIVES (ABSTRACT) 


notes on selecting software by Birket Foster, m.b.foster associates Itd. 


2755 draper place, ottawa phone (613) 820-5067 


The objective of this talk is to help hp3000 users in the software 
selection process. It is recognized, that many applications and 
utilities could never be written using in-house expertise or 
resources (adager, quiz,qedit, 8image, etc) there is a growing 
community of HP3000 software vendors to which many HP3000 sites 
are turning to speed the systems development life cycle. 


For most sites the process of selecting software is a new one. 
This paper presents a framework to help hp3000 users avoid the 
pitfalls of purchasing someone elses software to process their 


application. 
The areas, covered in this paper are: 


1. introduction 
2.the selection framework 
a) scope 
b) features 
c) rating system 
d) selecting committee 


souces of supply 

other information required 
the decision 

the legal contract 
conclusion 


“OUT ES CG 


HeHREE® cOoRY, BUT DUE TO POSTAL STRIKE THIS PAPER DIDN'T REACH US 


IN TIME, ASK THE AUTHOR FOR COMPLETE DOCUMENTATION ~ (EDITOR) 
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JOBLIB/3000 - an Interactive Pre-processing System 


Intraduction 


This presentation is a progress report on the development work made 
at Oy Porasto Ab since 1977 to make better use of the automatic data 
processing capabilities in HP3000 systems. For earlier reports refer to /1/ 
and /2/. 


Most automatic processing is in hatch mode, but the old way of batch 
using "fixed" stream files suffers from some severe drawbacks: 
- security of passwords on JOB stream files 
- troublesome updating of parameters and optional parts of 
: streams when using general purpose editor programs, which 
often leads to mistakes, and 
- many copies ahd versions of same stream files on disc 
- documentation problems of stream updating with editors in 
transferring the JOB preparation and initiation work to end 
users of the system 
- a typing error in the filename of a :STREAM command may 
start an undesired JOB. 


Too often these problems are avoided by letting end users do the work 
from time to time, makina them wait for the execution of a series of 
tasks on-line, even if all responses could be supplied beforehand. 


These problems can be solved easily hy pre-processing techniques. 


That is by updating the stream file under control of a qeneral purpose 
pre-processing program, according to stored processing rules for the 
particular job stream (or task), To provide best support for the user this 
pre-processing must he interactive. | 


J3 2 


JOBLIB/3000 system 


The problems listed above are solved by JOBLIB/5000, general purpose 
pre-processing system for HP3000, in the following ways: 


In the JOBLIB system, job streams are gathered as "job templates" 
into special library files, leaving all information concerning user, account, 
group and passwords out of the !JOB-lines. 


To initiate a job stream, a user simply starts the program JOBGEN, 
provides the name of job-library (default is JOBLIB) and the particular 
JOB required. Passwords are either supplied automatically from some 
secure data base (this is a new option in JOBGEN 5.5) or they are 
prompted from the user. 


Updating of parameter values in the stream is made by character 
string replacement operations, using mnemonic string variables, the only 
data format for variables in JOBLIB command language - job generation 
language (JGL), the lines of which are inserted in the job templates to 
control the flow of pre-processing. The string variable processing is 
implemented in a very powerfull way providing full text processing 
capabilities found in many programming languages, and they can be used 
also as numeric variables if the character string value assigned to them 
happens to be numeric. Of course this can be ensured by some data 
checking facilities of JGL. 


In many pre-processing systems, the value assignment for string 

variables is made by commands such as 

DEFINE (identifier, "value") 
(see /3/ p. 251), but in JOBLIB system we use automatic assigments of 
the type 

SET identifier="value" 

..COMP identifier=(arithmetic expression) 
and interactive assignments of type 

-DISP <advice> 

READ identifier . ="default"; checking rules . 

where the preceeding ..DISP commands are used to provide the user with 
further information concerning the prompted parameter value. 


Values of string variables can be any character strings of 0 to 80 
ASCII characters in length and restricted only by the data checking rules, 
if used. Currently there can be up to 150 different string varibles used 
in one job definition. 
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The assigned string value will then be replaced at every occurence of 
the variable name, preceded by "&", in any lines of the job template that 
the name occurs. These are then copied into JOBGEN work memory 
before they are interpreted and/or copied into the final stream file. 


Values of string variables can also be used to control the flow of 
pre-processing by the structured commands 
wIF , .WHILE and .CASE 
where the values of string variables can be tested in the condition part of 
the command using relational and logical operators (which will be fully 
implemented in release 5.5). This provides the possibility to select 
alternative or optional parts in the final stream automatically, according 
to parameters supplied by the user. 


To achieve full flexibility and automaticity in assignments, replace- 
ments and conditions, we have implemented substring operations and string 
processing functions such as: $LEN(s), $UPS(s), etc. 


For maintenance of parts common to many JOBs and to make use of 
generalized parts, we have also implemented a procedure library facility in 
JGL. This feature has been especially appreciated by those users of 
JOBLIB system, who are familiar with the procedure library facility of 
IBM’s operating systems. The procedure library provides an easy way to: 
- use parametrized QUERY reports included in different JOBs 
- maintain tables of parameter values in separate libary files 
- define generalized parts of JOBs for making backups or 

for other routines, etc. 


The procedure calls (..INCL -commands) can be hierarchical and even 
recursive. The outer pre-processing can be secured by using local string 
variables inside the procedures, and using string variables as parameters in 
procedure call. Values can be transfered into and out of the variables 
used in procedures, just like in programming languages. 


Instead of a procedure, a whole file can be included during the 
pre-processing. This provides possibilities for including for example 

= stream parts generated by some other programs into the final 
stream . 

- source programs with inserted JGL control lines and string 
replacements into a compilation stream, making use of 
interactive pre-processing for COBOL programming. This goes 
even far beyond the capabilities of COBOLII. 
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Benefits 


The JOBLIB system makes batch jobs easier to use, and it provides a 
comprehensive technique for system personnel to submit job preparation 
work to operators and even to end users. All the user has to know is the 
name of the JOBLIB, the name of the job, and how to answer the 
questions presented in the job template. 


For system personnel, the JOBLIB system provides the possibility of 
tool-jobs, a flexible test environment, a procedure library for common 
parts, and a good on-line documentation technique. From elements of 
macro processing and programming languages, we have created a new and 
efficient "productivity tool" that provides a dynamic and flexible extension 
of traditional job streams. The JOBLIB system is not just a library 
system, but a new approach to batch processing in an on-line environment. 


The benefits of JOBLIB system are clear: it saves human and 
computer resources, time and money, eliminating errors and increasing 
security and productivity. 


Future plans 


We are currently (August 1981) using release 5.4 of the JOBLIB/3000 
system and we are developing release 5.5. 


As the main trend of development we are making JOBLIB/3000 as 
"open ended" a system as possible, This means that it can be used in 
different kinds of system environments, it can be integrated with different 
software, and it will be more and more customizable. Examples of this 
are: 

- We have separated all program messages of JOBGEN into a 
separate catalog file, so that they can be easily customized or 
translated into any other national language that can be written 
using ASCII letters. 

- We have added the option of using a fully customizable data 
base, to supply required passwords into !JOB-lines of stream 
files. This is delivered with sources of interface modules and 
using pre-processable installation streams. 

- Currently JOBGEN supports SLEEPER as the scheduling 
monitor, but this will be made more open to other systems 
using a separate :STREAM -time reservation module delivered 
on source level. 

- JOBGEN will also be accessible as a son process of customer's 
own application monitor programs and it can be controlled 
directly by a message file of procedure type, generated by the 
father process. 
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Availability 


We at Porasto belive that the JOBLIB system is of use in almost all 
HP3000 installations and we have made it available on an yearly rental 
basis, Currently it has been installed in 20 HP3000 systems in Finland 
and Sweden, For further information, please contact Oy Porasto Ab, att: 
Martti Laiho, Toolontullinkatu 8, SF-00250 Helsinki 25, FINLAND, 
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ABSTRACT (1) 


TOPIC:USING !MAGE-3000 TO ESTABLISH AN ORDER PROCESSING--F INISHED 
GOODS INVENTORY ON-LINE DATA BASE SYSTEM 
WALSIN LIHWA CABLE CO.LTD.,APPLY IMAGE-3000 TO ESTABLISH AN ON-LINE 
DATA BASE SYSTEM WHICH INCORPORATES 4 MODULES----PRODUCT DATA MODULE, 
CUSTOMER INFORMATION MODULE, ORDER PROCESSING MODULE AND FINISHED 
GOODS INVENTORY MODULE. THESE MODULES ARE LINKED BY SEARCH-ITEMS. 
USING THE CAPABILITIES OF IMAGE-3000, A TWO LEVEL HIERARCHICAL DATA 
BASE SYSTEM CAN BE [IMPLEMENTED AND SUITABLE FOR ON-LINE OPERATION, 
SEVERAL OTHER TRANSACTION FILES ARE ALSO RELATED AROUND TO THIS 
SYSTEM TO FORM A TOTAL INTEGRITY. 
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WALSIN LIHWA ELECTRIC WIRE & CABLE CORPORATION 
The WALSIN Bulging 219 Chung Hsiao fF Road Suv 4 Tape: Tawan R OC 
Tel 7712221120 Lines! P O BOX 22926 Teiex 11516 WALSIN Tame: 
Cable WALSIN Tape: 


ju 2 


COMPUTER GRAPHICS, A POWERFUL INFORMATION TOOL 


SIGMUND Hov MoeEN 


FREDERIK MAJOR 


SIGMUND Hov Moen A/S SyDVARANGER. KIRKENES. Norway 


FREDERIK Mayor 


THe SHip RESEARCH INST. OF NoRWAY TRONDHEIM, NoRWAY 


J5 1 


COMPUTER GRAPHICS, A POWERFULL INFORMATION TCol, 


Authors: Sigmund Hov Moen, A/S Sydvaranger, nirkhenes, Norway 
Fredrik Major, The Ship Research Inst. of Norway, 


Trondheim, Norway 


Information transfer from/to human beeings is a central part 

of a computer system. We will here show how Computer Graphics 
can make man machine communication extreemely much more 
efficient. A case study of a Norwegian mining company, 

A/S Sydvaranger, will illustrate this fact. This company uses 
Computer Graphics for information transter between people at 
all levels. 

The graphic system in use for the above mentioned application 
is GPG S$ - F (General Purpose Graphic System in Fortran) which 
is the standard graphic system for Norwegian users. 

This standardization has been pushed through by NORSICD, The 
Norwegian Cooperation in Computer Graphics, formed by Norwegian 
users. 

GPGS-F which here will be briefly described (A more detailed 
description in (1) ) is implemented for |I2 different computer 
types with device drivers for I7 different graphic devices. 
There are approximately 70 installations of the sysyem today 


throughout the world, 10 of theese are HP 3000 installations. 
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BRIEF DATA ON AKTIESELSKABET SYDVARANGERs PRODUCTION 


THE BASIS for the company's existence are the 
very substantial iron ore deposits situated on the 
Kirkenes-peninsula combined with excellent deep 
sea harbour facilities in Kirkenes, only 5 miles 
‘rom the main orebody at Bjornevatn. 


AKTIESELSK ABET SYDVARANGER was 
counded in 1906. The company today has 2300 
ihareholders. The Norwegian government owns 
31% of the shares. 


THE PLANT is today designed and built for a to- 
al production capacity of 2.5 million metric tons 
ron pellets (minimum 65% Fe). 


THE MINING in Bjornevatn is carried out as an 
open cast operation. The open pit is considered 
large by Norwegian standards. The present pro- 
duction plans operate with a stripping ratio of 2,5:1, 
i.e. 15 million tons of waste have to be removed to 
enable recovery of our annual production of app- 
rox. 6 million tons of magnetic ore which contains 
about 30% iron. 


DRILLING is mainly carried out by means of By- 
cyrus Erie 60 R rotary drills producing holes of 12 
1/4 inch diameter. 


BLAST CHARGING is done with ANFEX (Am- 
monium nitrate-fuel explosives) and TNT-slurry. 
Each hole is charged with approximately | ton of 
explosives. Total blast size varies between 75.000 
tons and 750.000 tons of material broken, and the 
equivalent amount of explosives used varies 
between 30 and 300 tons. 


1 COMPUTER GRAPHICS IN A MINING COMPANY 


1.1 A/S Sydvaranger 


"Raw data’. 


LOADING OF MATERIAL is carried out with 
track mounted P & H electric shovels with 7 m3 
bucket capacity and one Marion 191 and one 
P & H 2100 shovel, each with 11 'm (15 *yds) buc- 
ket. In addition to this several wheel loaders are 
used, the largest of which is a 10 ‘yds Caterpitlar 
992 and Dart 600 12 ‘yds. 


ORE AND WASTE TRANSPORT is taken care 
of by a fleet of 100 and 150 tons Lectra Haul and 
Haulpack trucks. 


PRIMARY CRUSHING is done in Bjernevatn by 
means of (two) 54° Nordberg gyratory crushers 
(54° wide intake opening) which is normally set at 
5%" closed side, giving ore crushed down to app- 
rox. minus 5”. 


ORE COBBING is carried out on conveying it 
over large magnetic drums separating most of the 
waste (15% - 20 %) from the ore before it is dis- 
charged into the ore storage silo. 


THIS CRUSHED ORE is transported by our own 
railway in 60 tons capacity cars and dumped in la- 
rge ore bins at our secondary crushing plant. 
Each train has 20 cars and thus carries approx. 
1200 tons. 


OUR TWO STAGE SECONDARY CRUSHING 
PLANT uses 7’°Symonds cone crushers and re- 
duces the ore in size to approx. minus | inch. 


PRIMARY GRINDING of this material is carried 
oul in a two stage ball mill process where water is 


Our 
the process 


The mine is an open fit one andcontains low grade iron 
ore which are concentrated to the proper quality ina 


conventional crushing/milling/separating plant. 
final product is iron pellets which is small balls (about 


a small town on the russian border far up north an far 
half an inch in diameter) containing 65% iron. 


A/S Sydvaranger is a mining company situated i Kirkenes, 
east in Norway. 


Further information about the company and 


is given on the next pages. 


added as a carrying agent. After this grinding 
approx. 30% of the material is separated out as 
waste over series of magnetic drums. This product 
or concentrate, is ground further to make it suit- 
able for pelletizing. 

This concentrate contains approx. 68% Fe. 


PELLETIZING, a process which transformes the 
concentrate into the shape of small 2" diameter 
balls is carried out by adding approx. 1% of a 
binding agent called bentonite (basically a spec- 
ial, dry, finely ground clay). This mixture is rolled 
in large-inclined drums which produce small balls 
(green pellets). 

These are dried over a travelling grate, preheated 
and sintered. The «pellets» will have a temperat- 
ure in excess of 1000° C when leaving the grate. 
From here they enter a rotating oven or kiln where 
they are heated further to approx. 1350° C. 
The hot pellets are now discharging into a cooler 
section where they are cooled down to 20-30° C by 
a forced air draught. 

This product is stored in a large 400.000 tons ca- 
pacity silo blasted into the mountain. 


THE HARBOUR in Kirkenes is a good natural 


harbour which has little problem with ice in win- 


ter, in spite of its focation at 70° North. 
The harbour facilities has a capacity for loading 
ships up to 150.000 tons at a rate of 
approx. 4.000 /h. 


AKTIESELSKABET SYDVARANGER today 
has approx. 1250 employees in Ser-Varanger 
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1.2 An EDP pioner in Norway 


Within a year a process control machine (Siemens R 30) will be 
installed to improve production quantum- and quality control 


A/S Sydvaranger installed its first EDP equipment = 1963. : in the pelletizing plant. 

i 
Sritaee (eles SSC einer Sep rtarnmae a8 ere Ape enone a We are also testing out a mineral evaluation system (Mineval), 
univers es. 


which is a program based on first generation graphical methodes. 


The first machine was an IBM punched-card-based 421. The total investment in EDP equipment so far amounts to approxi- 


Part of the companies staff-department-routines were implemented mately 5 mill. kroner. (1 mill. $) 
in the first place and soon afterwards a first version of a 


tock trolling and accounting system The hardware configuration consists of approx 30 terminals 
stock contro g ; 


of all kinds - six of them at the companies headquarters in 


Oslo. 
In 1966 a new and more powerful computer was installed (IBM 360/ ° 


20) and the main part of the companies accouting system was 
"Somputerized". 


An information system for the mining operations was also devel- 
loped. 


In 1974 the 360/20 was scrapped and after a short interludium 
where different alternatives were tested, the company in 76 
bought and installed a HP 3000. 


Today A/S Sydvaranger heavily depends on the computer in the 
following areas: 


- Production reporting 
. Accouting 

. Stock control 

. Payment of wages 





Fig. 1. Ny Sydverangers maskinkonfiguresjon 


The EDP-department today counts 11 persons, 7 of them are 
programmers. 


Our main effort is to improve the information contained in the 
great variety of EDP-reports, and also get the computer and 
computer methods accepted everywhere in the company. 


Considering the fact that EDP less than 20 years ago was a rarity, 
it is not surprising that use of the modern microprocessorpowered 
computers have created a lot of discussion, - both seen from the 
economic and social point of view. 


What is the outcome of the millions that have been invested in 
EDP-equipment the manager is asking. What will happen with my 
job is the workers question. 





One of our projects to reassure both parts is to supplement the 
numerical reports with better understandable ones, Today 
this is possible not least due to computer graphies. 


The companies data flow 


Drawing machines, plotters, graphical screens, digitizers etc. 
has moved the computer a big step towards the people. 
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{.3 Graphic Hardware 


The hardware is a mixture of a number of units as shown below. 


OIG. 
TABLE 
PROSPECTING 


OFFICE 


- Ca 


ac MINE 
HAROCOPY TABLE OFFICE 
; KIRKENES 
TEKTRON ix 
4054 
EOP. 
HP OEPARTMENTS 

£990 KIRKENES. 


PLOTTER 
aig SYDVARANGER TE KTRONIX 


CONFIGURATION _ ae aba 
GRAPHICAL 3000 PELLET PLANT 
EQUIPMENT. GPGS-F a Seen KIRKENES ~ 


















HP 2648 
CALCOMP 
DRAWING 
MACH INE 
MAIN PLOTTER 
EDP. - DEP OFFICE HP 
KIRKENES. OSLO 


All units is online to the HP3000. Some of them are multi- 
plexed on medium capasity telephon lines. 
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1.4 Graphic Software 


Hardware is mentioned - ccmputer journals are full of visuali- 
zation units of all kinds. Less is spoken about software. 

How do you program a 3 dimensional rotation picture; how do 
you program a histogram? Do you hav to write a special program 
for every graphical output unit? 


So many questions. And so many traps to be caught in. 


One way to get rid of most of the difficulties is to choose 
a standardized graphical software package. 


The GPGS-F is such a system. Standardized by NORSIGD, a 
norweulan organization formed by people interested in graphics. 


GPGS-F is fortunately implemented on the HP3000 system. The 
system basis is a set of fundamental routines drawing lines, 
circles, character strings, numerics etc.. 


Besides the routines already mentioned the system contains a 
number of special drivers for the most popular and common 
graphical units. 


The system is very well documented and easy to learn. 
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1.5 System philosophy 


The graphical system is an online one. On the user's commands 
it are fetching data from the big databases containing up-to- 

date information about the stock, the production, the accour- 
ting etc.. The extracted data is then presented as diagrams.. 


The user's of the system are not computer specialists, they 
might not even be interested in computers. They are mine 


foremen, geologists, production planers, clerks, directors etc.. 


Therefore the user interface to the system is very important. 
The online dialog should be adapted to the user's language 
and way of thinking. 


USER COMMANDOS. 
(ONLINE ) 


USER 
INTERFACE 






GRAPHIC AL 
SCREENS 





ONLINE 
DATABASES 
FOR 






STOCK CONTROL| —————», 
ACCOUNTING 


PRODUCTION 





ZO-AAMECKOAN PFaPpo 





ONLINE GRAPHICAL REPORTING SYSTEM ‘4/4 SYDVARANGER. 
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This is obtained by giving the user a series of commands to 
choose between. 


A valid command leads to a conversation like the following 


command name identifying the user's main topic of 


interest 
additional information f.ex. machine number 


period of interest 
output media 


Not valid input at all levels are followed by a very friendly- 
sorry - and a recommended continuation. 


The languageis plain and simple norwegian, not a word is re- 
minding the user of the bits and bytes, the full duplex, the 
recursive procedures, the interlaced memory - and whatsoever. 


As a first aid the HELP command gives an overall information 
about the system. 


1.6 Data collection 


The systems practical value fully depends upon the quality of 
the information put into the databanks. Tt has therefore been 
necessary to establish a data reporting program. 


A great number of reports is collected and registered into 
the computer. 


This is also done online by means of masking technics. 


On the next page the data collection system for the production 
data is shown. 
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Part one contains examples from the economics reporting system 


(diagram 1 - 3). 
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The example section is devided in three parts. 
Part two shows some mining reports (diagram 4 - 6). 


1.7 Examples 
(diagram 7 - 8) 
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GPGS-F, A PORTABLE DEVICEINDEPENDENT GRAPHIC SYSTEM 
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2.! Background 


During the early seventies, computer graphics was introduced 
in the research and commision work of The Ship Research 
Institute of Norway (NSFI). In this process lack of suitable 
standardized basic software was very badly felt. 

About the same time similiar problems arose in other research 
institutions and in the industry. 

A national special interrest group in computer graphics grew 
up from the loose attempts of cooperation between the involved 
parts. 

NORSIGD (The Norwegian Special Group in Computer Grepiics) 
was founded in 1975 and has since then formed the basis of 

a very good cooperation between most Norwegian computer 
graphics users. 

The main task for NORSIGD has been developing a standard 


graphics software system for Norway. 
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2.2 History 


The GPGS system was originally designed by Rekencentrum, 
Delft University of Technology, The Netherlands and Science 
Faculty, Catholic University Nijmegen, The Netherlands in 
1972. A version of the system written in standard Fortran 
has been developed by NORSIGD. The first Fortran based 
version was released in 1975 and named GPGS-F. GPGS-F has 
been under continous development since the first version 
was released. This work has been guided by annual user 
meetings. The result of these meetings has been new 
features and minor changes to the system. 


2.5 Device control 


GPGS-F provides device independent programming with choice 
of graphic device at run-time. 


Figure 1 shows how the device independancy is obtained. The 
device independant part produces the same picture code for 
all devices, and the device driver(s) translates this code 
to the bit pattern required for the actual device. The 
device independant code is put on such a level] that advanced 
graphic devices may be used in an efficient way. Examples 
of such functions are character, circle and marker genera- 
tion. GPGS-F will also be able to take advantage for the 
functions of more advanced refresh display such as hard- 
ware scaling, rotation and depth quing. 
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Fig. 1. MAIN STRUCTURE OF GPGS-F. 


Table 1 shows the current implementation status for GPGS-f. 
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2.4 Graphic elements 


By single calls to the basic routines of GPGS-F, the 
following graphic elements may be ‘generated: 


- straight lines 

- set of straight lines 
-~ circles/circle areas 
- text 

- markers 

- functions 


All graphic elements may be hardware generated by the graphic 
device. 


The elements are defined in a user defined coordinate system 
(2-or 3-D Kartesian) and are fully transformable. 


2.5 GRAPHISTO - Graph and Histogram plotting 


It goes up and down tn Lita 





GRAPHISTO(b)is a subroutine package which using the basic 

routines of GPGS-F can produce curve~-, bar- and piecharts. 

The package was designed to remove programming effort from the 
tasks of producing standard plots. GRAPHISTO is aimed at easy 
presentation of one variable data. 

An advantage when using this package is that it can be entered 

at different levels. When the user wants to produce one of the 
standard charts of the system this can be done by one simple call. 
If this standard chart does not satisfy the requirements for the 
plot, user can enter the system on a lower level, composing the plot 
he wants. The user can even go down to the basic routines of 
GPGS-F and mix these with the GRAPHISTO calls. 
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GRAPHISTO provides 4 so-called ‘chart’ routines that will in 
answer to a single call draw a complete diagram with anno- 
tated axis, texts on axis and datapoints. 


The types of plots provided through these 4 routines are: 


- Histogram with labels under each bar and linear or 
logaritmic axis in x and y. 

- Table of lines with straight lines | etween plots. 

= Smooth curve through specified points. 

- Pie chart. 


These 4 routines use the basic GRAPHISTO routines as axis 
drawing, range computation, 'nice' value computation and 
curve plotting. The lower level routines are also avail- 
able to the user and offers possibilities for sophisti- 
cated non-standard plots like multiple axis, marking special 
data points etc. Appended to this chapter are some plots 

to demonstrate the use and possibilities of GRAPHISTO. 


Figure 7 Shows some plots produced with GRAPHISTO. 


Available facilities are: 
Chart plotting: 


- Simple and smooth (cubic spline) curves in different 


linestyles. 
- Histograms. They may be plotted with or without hatch- 


ing of bars in any angle. 
- Pie charts with texts and percentage of total pie. 


Axis drawing 


- Near to plot on either side of plot. 
- Through any data or page value. 
- Several parallell with different units. 
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Figure 7. GRAPHISTO example plots. 
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Axis 


annotation: 


Cn either side of axis 
Numeric or text labels 

Any character size and angle 
Upper and lower case 

Extra tick marks 

Title 


Along x- or y-axis 
Linear or logaritimic 
Any line type or ‘+' at grid crossings 


Datapiotting: 


Table of values in x- and y or functions 
Simpte connected points 

Interpolated curve through points 
Markers at points 

‘Undefined’ points 

Automatic data indexing 

Automatic data incrementing 


layout: 


Centered heading 

Positioning of dataplotting area in users window 
Bar and curve legends 

Frame 


Miscellaneous: 


'Best-fit' range computation of data contained in 
array or function. 

'Best-fit' label format computation. 

Conversation between coordinates in users window 
and in plotting coordinates. 
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Error Reporting: 


The routines in the GRAPHISTO system uses the error 
system of GPGS-F. This includes parameter checking 

and print of routine number, where error occured. Also 
the number of calls made to GRAPHISTO routines and 
wrong parameters are printed. This makes it easier 

for the user to find place and reason of error. 


10. SURRENDER, 3-D SURFACE PLOTTING 









[TL A Mh 


SURRENDER (3) is a subroutine package for drawing bivariate 
surfaces in 3 dimensions. GPGS-F basic routines are used for 
line drawing and GRAPHISTO routines for axis drawing and curve 
smoothing. 
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Base for al] SURRENDER plotting is a rectangular x-y grid 
(matrix) with z-values in each node. A surface with M grid 
points in x-direction and N grid in y-direction will be 
stored in a Fortran DIMENSION ARRAY (N,M). 


This grid may be rendered as a 3-D perspective plot of the 

grid (Isolines any combinations of x,y and z) with hidden lines 
removed or as a 2-D contour map (Isolines for any of x,y or z). 
Also other usefull facilities like drawing axes, marking points 
etc. are available and will be further explained later. 


The package is built up much the same way as GRAPHISTO with 
some routines that makes a complete plot in one call, and 
others to add features for a more sophisticated plot. 


Example of minimum effort plot: 


DIGERSTON WORK C269) VeCh) PAV EO910 31), 10703) 
DATA TDEV/E/.VP/0.9,0.3,6.6.6. 3/ 
DATA 1IbLUE/20/, 1 KED/60/ 


C COMPUTE THE FUNCTION "SINCX)*®STNCY)ZOK*PY)* 
Cc 
DO 1C00 TY=-15,15 
Y=FLOAT(TY) 
SINYY=1.0 
IF (1Y.NE.G) SINYY=SIN(Y)/Y 
po 1600 TxX=-16,1% 
X=FLOATCIX) 
SINXX=1.0 
IF (1IX.NE.O) SIRXX=STIN(X)/X 
ZMAT(1X4160, TY2 16.210. 0*STNXX*®SINYY 
1000 COKTINUS 


C 

C MAKE MINIMUM EFFORT CLOT 

C 
CALL NTTDEVCOLDEY) 
CALL BGHYIC(1) | _ 
CALL PLOUAZCZMAT .31.31.-15..18..218..18. TR ORK, 20) 
CALL ENDPIC 
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Hidden line removal: 


By default the hidden lines will be removed. To do this 
the system uses a working array to be supplied by user. As 
the needed size of this array is dependant upon the number 
of points to plot, this method gives no restrictions about 
number of points. 


Setting focal point and eye position: 


The surface may be seen from any point in space and some routines 
are used to set this point either using cartesian or spherical 
coordinate system. The viewing may be either axonometric or 
perspective. 


Adding axes to the plot. 


Axes may be added by a call to a single routine giving 
standard axis annotation or by several calls to GRAPHISTO 
Axes routines fer special labels and format. 
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Contour plots. 


Contour plots consists of isolines in the z-direction. The 
range and number of contour lines may be given, and they 
may be added to the perspective plot or plotted as a separ- 
ate 2-dimensional plot. 
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Default contour plot. 
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1. INTRODUCTION 


This paper is primarily concerned with the system dev- 
elopment cycle in a business environment. This does not 
mean however that data analysis should not be performed 
in other environments, e.g. ~ scientific = 

but in order to demonstrate its usefulness, a specific 
area has been chosen. The paper has also concentrated 
on the logical construction of IMAGE and using an 


HP3000, but many aspects can be seen to apply to other 


file systems and ranges of hardware. 


2. WHY USE A METHODOLOGY? 


A 'method' is a procedure for carrying out a certain 

task. <A 'methodology' is an integrated set of procedures, 
founded on consistent basic principles, which provide 

a complete framework within which a given task can be 
Performed. A methodology is used to perform these 


basic functions. 


7 Highlighting of problems at an early stage. 
The development process is structured to allow 
critical management, user and technical decisions to 
be taken at the right time, i.e., as early as 


possible. (see Figure 1 over) 
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Figure 1 


—_—_—_—_——— 


(C.G. Davis "Requirements Problems in large real-time 


systems development") 
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Check point facilities provide a means of communication 
between all levels of personnel concerned with the 


project. 


2a De Proof of progress. 

DP management is under constant pressure to show results. 
Without a methodology all we do is push for early 

system completion, thus instead of the project being 


time-shared as in Figure 2 (over), 
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we save time in the analysis, resulting in Figure 3. 


3. 2. Consolidation across applications 


Figure 2 IDEAL : 
Bigure 2 RERE - file collation 
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ANALYSIS - integration of processing 
DESIGN 


ko ones Lack of control 


- satisfying new application requirements 


IMPLEMENTATION MAINTENANCE 753 - availability and use of data 


40% 


When the introduction of the database philosophy came, 


it was not necessarily a philosophy centred around Database 


With a methodology however, we can prove our progress at Management Systems but more the acceptance of the need 

each step by producing checkpoint documents. A methodology to share data. Data is the basis of information flow 

must therefore provide: across the functional boundaries within an enterprise 
- guidelines which ensure that we don't overlook things as represented in Figure 4. 


(not rules as they are too inflexible) 


- an approach which is top-down or outside-in and modular Figure 4 


- easily understood diagrams for communication ORDER 
- standards for use and documentation 
MANUFACTURING 


WAREHOUSING 






PURCHASE 





3. DATA - A VALUABLE RESOURCE 


For years the value of data was grossly under-estimated. 


This meant that the emphasis was on the application INVOICING 


approach, where, for each application, the data 

would be defined again resulting in the following The definition of a database should be: 

difficulties: an organised, integrated collection of data which 
Sie. iL Duplication of data - is structured to reflect the real world of 


: ; ; ; rpris 
- inconsistencies of value, timeliness and meaning the enterprise 


- cost of storage 
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- is stored independently of programs which use it 
- satisfies the requirements of multiple user 
application 
or all of the above may be summarized quite simply 


by defining a database as "a common pool of shared data". 


However, new problems soon became apparent to the 


designs of early database systems: 


- lack of procedures to make and document critical 
agesign decisions 

- development of single-application oriented databases 

- adoption of a bottom-up approach to data analysis 
meant that the designs became inflexible 

- failure to fully exploit the r6le of data 
dictionary/directories 

- no allowance (or design) for database recovery 
or re-organisation 

- the database project was usually seen as a file 


conversion exercise 


To summarise - the database philosophy evolved from a 
need to share data, but whilst there are many benefits 
for the use of a database there are also pitfalls in 


the development stages. 
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4. WHAT IS DATA ANALYSIS? 


Data analysis is part of the systems development cycle 


as shown in Figure 5. 


Figure 5 
The Systems development cycle 
BUSINESS 
ANALYSIS 
CONCEPTUAL 


DATA ACTIVITY 
ANALYSIS ANALYSIS 







LOGICAL ACCESS PATH 
LOGICAL APPLICATION 
DATA SYSTEM DESIGN 
STRUCTURE 
DESIGN 

PHYSICAL 
PHYSICAL 
DATA STRUCTURED 
STRUCTURE PROGRAMMING 
DESIGN 






SYSTEM 
IMPLEMENTATION 


The objective behind each part is as follows: 
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METHOD OBJECTIVE 


Business Analysis (BA) To define the business area 
boundaries for analysis needs, 
at a high level 


Data Analysis (DA) To analyse the data resources 


Activity Analysis (AA) To define the users' 
information handling processes 
Logical data structure To map the data model to 
design (LDSD) the logical data structure 
Application system To translate the user information 
design (ASD) handling processes into a 
technical application system 


design 


The most important factor to note is the early split 
between data and functions. Most of the emphasis in other 
System development methodologies has been on the functional 
Side, typically on the programming effort. Although 
programming errors are one direct cause of costly and 
inflexible systems many of the errors can be traced back 


to errors in the analysis and design stage. 


What is fundamentally wrong with many approaches is that 
no method exists for analysing and describing in a concise, 
user-oriented way, the business data and how it Operates, 
divorced from any considerations of how the system will 


eventually be designed. 
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It is often desirable, and should be possible to analyse 
a business without any prior constraints on how parts 

of the business are to be computerised and which 
business functions will form the basis of computer 


systems. 


In many approaches other than Data Analysis, the 

emphasis is placed on determining and analysing the "output 
reguired", (i.e. listings, reports, computer files, 

etc. - a dangerous practice in itself, as information 
requirements are never static) and then expressing the 
results in terms of computer files, English narrative 
descriptions (often long and complex) of the "processes 
required", and technical flowcharts of the flow of data 
through the system. The results of this approach are 
apparent - inflexible systems which are not resilient 

to change and whose development is often unco-ordinated 
and fraught with problems. The underlying cause is that 
the business was never fully understood before the design 


stage. 


One approach which seeks to remedy this lack of an 
analysis methodology is known as data analysis. Database 
Consultants Europe BV (DCE) has sucessfully used this 
technique for a number of years during which time the 
initial concept has been developed into a complete analysis 


and design methodology. 
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Data analysis is a method used to understand and 
document a complex environment in terms of its data 
resources. The resultsof data analysis are summarised 
in a diagram known as a data model. Detailed results 
are documented on specially designed forms. The input 
and output of Data Analysis can be summarised as in 


Figure 6. 


Figure 6 
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54 WHERE TO BEGIN? 


To initiate the task of Data Analysis the following 


tasks should be performed: 


Dee Fie Gaining support 
- from management 
- data processing staff 


- user departments involved 


5). Dy Definitions 
- of the objectives 
- of the timescale 


- terms of reference 


oa Design and acceptance 
- Data Analysis standards as compared 
with existing standards 


- Documentation 


5. 4. Anticipation of possible unfortunate 
discoveries 
- irreconcilable coding systems 
- inconsistent existing data 


- incorrectly interpreted reports 
5. 5. Education and training 


- theory and methodology 


~- detailed procedures. 
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6. DATA AREAS AND RESOURCES 


When choosing the data area for analysis, it should be 
small enough to be manageable and not too complex that 
an overview cannot be attained. There should be clear 
cut definable boundaries with a minimum of interaction 
with other areas. It should be independent of, or well 
defined in terms of, specific applications. There should also be 
abusiness requirement for applications to be implemented 
in that area, or for improvements to be made to existing 
application. The data resources can be categorised in the 
following way: 

= Personal knowledge and ideas 

- Clerical records 

- Manually produced reports 

= Correspondence 

~ Computer files 

- Other computer readable data 


= Computer produced reports 


7. DEFINITION OF ENTITIES, ATTRIBUTES AND RELATIONSHIPS 


Within data analysis, there are three major components: 


7. 1. Entities 
An entity is something of fundamental importance 


to a company. It is thus something about which 
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data will probably be kept in an information 
handling system, e.g. objects, people, places 


or abstractions Such as events. 


Wages Attributes 

An attribute is a basic unit of information 

which describes an entity. Within the company 
environment, an attribute cannot usefully be 
sub-divided into other units of information. 

An entity must have attributes if it is of interest to 
the company, e.g. the entity "insurance policy" could 
have the attributes policy number, date policy started, 


person's name, person's date of birth. 


7. 35 Relationships 

A relationship is an association between entities, 
e.g. the entity 'order' is related to the entity 
‘order line', the entity 'car' is related to the 


entity ‘part’. 


There are no theoretical rules which can be applied to 

decide when an object is worth being an entity or attribute 
until the company environment is known to the analyst. If 
the object is not of fundamental importance to the enterprise 
then it is not worth keeping information about it. For 
example, can a building be .an entity? In the case of a 
company which simply exists in one building the answer 

could be 'no'. However, in the case of a construction 
company or an electrical installation company the answer 


would most definitely be ‘yes’. 
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A similar example for attributes is a 'person's weight’. 
In the case of a vacuum cleaner sales company the answer 
would be that a ‘person's weight' would not be an attribute 


but for a hospital it would. 


8. ANALYSIS OF ENTITIES 


In order to recognise entities it is important to ask what 
data or objects are within the chosen area(s). A first 
pass of definitions of entities and preferably their 
distinguishing or key attributes is made. The key point to 
remember is that the focus is on entities not processes. 
However it is important to ask what events take place (e.g. 
job offers) in order to identify entities which are abstractions. 
It is advisable to check all input and output reports for 


other possible report entities. 


Js ANALYSIS OF ATTRIBUTES 


Once the major entities have been identified, determination 
of relevant attributes is performed by examining: 

= Manual files 

= Documents 

= Decision criteria’ (to identify implicit 

selection or distinguishing attributes) 

= Computer files 

For new entities it will be necessary to ask when data is 


needed to be kept about that entity. 
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10. 


PICTORIAL REPRESENTATION 


POr ah; Entities 


Entities are represented by a rectangular box 


with the name of the entity written inside the 


| | : | BANK | 
, PERSON POLICY ACCOUNT 


In the early global data analysis phase,only the entity 


box. 


name is written inside the rectangle. However, 
when doing the detailed data analysis it is 
sometimes convenient to include also the names 
of the identifying attributes. 

10... 2. Relationships 

Relationships are shown by drawing a line between 
the entities ,also showing the degree of the 
relationship. An abbreviated name of the relationship 
can be written alongside the line. (NB. entity names 
and relationship 


names are read in a clockwise 


direction). 


1Oa> Qe. Be One to One (1:1) 


The One to One degree of relationship is represented 


FAMILY 


by 







LIVED-IN 
LIVES-1IN 





HOUSE 
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pe es 


i.e. One house is lived in by one family and 


one family lives in one house. 


LOS. 2a; 22s One to Many (1:n) 
One to many degree of relationship is represented 


by 


CONTAINS 


BELONGS TO 





i.e. One order contains many order lines and one 


order line belongs to one order. 


10; 2. 3. Many to Many (n:n) 


MANNED-BY ; 


PROJECT PERSONNEL 


a 
PTAKES PART IN 4 





One project is manned by many personnel and one 


person can take part in many projects. 


FORMS OF RELATIONSHIP 


Relationships can take many forms 


11. 1. Optional Relationships 


COUNTRY pa ae, Ore MELE 


i.e. A country may or may not contain oil wells. 
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Lele {2% Partially optional 


PERSON 4 CAR 


i.e. A person may own none, one or many cars 


but a car must be owned by a person. 


1)... Involuted relationships 


MARRIED TO 


Fee, 


PERSON 


An involuted relationship is a relationship 
between occurrences of the same entity type, 


e.g. a person may be married to another person. 


ll. 4. Multiple relationships 









BUILDING 






COMPANY 





HAS OFFICES 
IN 


i.e. A company may Own many buildings and must 


have offices in many buildings. 


11. 5. Inclusive relationships 


CUSTOMER 





An entity can participate in the one relationship - "overdrawn ' 
only if it also participates in the other 


relationship - "has". 
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Tide. 6: Exclusive relationships 


FINISHED 
MATERIALS GOODS 





An entity occurrence may participate in any one, but not 
more than one, of a number of alternative or exclusive 


relationships, e.g. a car must be owned by either an employee 


or a department, not both. 


12. THE DATA MODEL AS A COMMUNICATION TOOL 


It is imperative for any methodology to be able to 


use the analysis results for communication purposes, 
Since communication must take place between the user of 
the information and the technician who is performing the 
analysis, it is also necessary to keep the pictorial 
representations as simple as possible to avoid misunder- 
standings and to enhance co-operation. No user has the 
time or inclination to sit down and discuss 50 or 60 
pages of documentation. It should also be remembered, 
therefore, that only those parts of the picture which 
pertain to the user's direct area of interest should be 


brought to him for discussion. 


At all times the picture should represent the real 


world of data and its relationships. 
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1é. 


A situation which must be avoided is the tendency 
to think in computer terms instead of user terms. 
It is also important to keep the representation in the 


simplest possible form. 


Figure 7 


Example data model - first pass 


COUNTRY 1 SALESMAN 4 ORDER LINE 


MARKETING . COMMISSION 
AREA 5 CLIENT ALGORITHM 


BRANCH OF 
COMPANY 








a 
ORDER 4 DEBTS 


It Should be noted that a hierarchical structure 

has been deliberately avoided so that relationships can be 
thought about more easily. Obviously models become messy 
and have to be redrawn when too many lines of relationships 


are involved. 


13. PRACTICAL PROBLEMS 
13. 1. Many to many relationships 
When a many to many relationship occurs it usually 
means that another entity can be identified between 


the two entities. 
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Exanple 


EMPLOYEE — d PROJECT 
i.e. An employee works on many different projects 
and projects have many different employecs. 


Because it is useful to have the attribute ‘length 


of time of employee on project' we are obliged to 


| PROJECT 


create the following situation: 


| EMPLOYEE | 


PROJECT 
ACTIVITY PER 
EMPLOYEE 


—— 





13. 2. Entity rdéles 

Entities which are similar but which have slightly 
different attributes depending on the value(s) of 
certain classifying attribute(s), are probably 
entity 'roles'. An entity réle is a sub division 
of an entity type which is difficult to separate 
from the entity type with which it is associated. 
E.g. A 'person' entity may be subdivided into 


'ADULT' or 'CHILD'. This would be represented in 


the following way: 





ee es eee 


PERSON 


ADULT 
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13. 3, Life-cycle réles 

Life-cycle réles are special cases of sub-type 
roles in which a sequence exists between the 
sub-types. This sequence is shown by a double 


arrow on the connecting line. 









OIL WELL 


_———— 










ABANDONED 
WELL 


EXPLORATION 
WELL 







PRODUCTION 
WELL 


13. 4. The Problem of Time 
Most time problems can be represented simply by 
showing the multiple relationships of present and 


past, e.g. 


| WORKED ON BY q 
PROJECT P——————41 ANALYST 
ARE WORKING 


ON 
14. ACCESS PATH ANALYSIS 


Access path analysis could easily be a large enough topic 
for discussion within a separate paper. In this paper the 
subject is summarised to demonstrate its relevance. To 
perform access path analysis the following tasks are 


performed. 


14. 1. For each access path, the entity types 
are listed in the order they are needed for a 


particular function. 
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14. 2, The selection criteria are recorded 


in terms of relationships and attributes. 


14. 3. It has to be recorded whether each 
entity attribute type is retrieved, modified, 


created or deleted. 


14. 4. It is also necessary to record any 


relationships created, modified or deleted. 


Example of Access Path Analysis. 


ACTIVITY ORDER ENTRY 

ACTIVITY DESCRIPTION 

Function 1] An order is received by telephone. The depot 
that will make the delivery is selected 
depending on whether the goods are bulk 
Or packaged. The order is recorded, and 


related to the delivery point and the 


depot. 
Function 2 The goods specified in each order line 
are validated. The order lines are 


recorded, linked to the goods and to the 
order or back-order as appropriate. 
RESULT 
Function 1 
First entry Delivery point- retrieved, selected by 
point 
delivery point name. 
Depot ~- retrieved, selected by bulk or 
package relationship. 


Order - Stored, related to delivery point 


and depot. 
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Function 2 Product - retrieved, selected by product 
Second 
entry point code. 
Stock - retrieved, selected by relationship 
with product and depot and updated. 


Order line - stored, related to order and 


product. 


15. MAPPING TO IMAGE 

The activities of data modelling and activity analysis are 
performed as far as possible without reference to 
implementation techniques available in IMAGE. The process 
of access path analysis does, however, identify alternative 
methods of achieving the required result, besides showing 
that occasionally the data model is deficient or inconvenient 
for handling some functions. At this point it helps to 
understand the range of logical structures available, in 
order to consider the alternative methods of representing 
entities in the Database, together with their attributes and 
relationships. IMAGE provides the capability to implement 
relationships through the use of PATHS though in practice 
there can be many restrictions on using that PATH. The 
simplest way to convert entities to logical records is to 
create one record type for each entity type, i.e. creating 

a DATA SET or a number of DATA SETS fur an entity. 
Attributes become DATA ITEMS. It may be necessary to divide 
attributes across more than one DATA SFT to provide 
efficient access to the most frequently used attributes or 
to combine several entities into one logical record. Any 


such changes should be checked against the data model. 
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16. TYPICAL STRUCTURAL PROBLEM 18. CONCLUSION 
A typical example of a problem presented by IMAGE is the Data analysis provides a good communication tool between 


following. the user wishing to understand his system 


COMPANY 4 DEPARTMENT 


This would have to be represented in IMAGE by 


and the analyst wishing to understand the user data. It 






EMPLOYEE 






provides a methodology which is flexible enough to adjust 





to new environments, not a checklist of standards which 
are inflexible to change. 
EMPLOYEE 
DEPARTMENT MASTER MASTER IMAGE is successful mainly because it is Simple to 
understand. With an easy-to-understand methodology and 


DBMS, implementation of systems becomes a smoother process 


COMPANY 
MASTER 


with involved, motivated users and a database ready to 


cope with future demands. 


DEPARTMENT EMPLOYEE 
DETAIL DETAIL 





Although it is an inconvenience to have to adjust the design 
to fit into these kind of circumstances, IMAGE has proved 
to be very simple for interpretation when looking to the 


ease of the DBSCHEMA. 


17. PERFORMANCE CONSIDERATIONS 

Performance considerations are quite often outside the scope 
of data analysis particularly as performance is usually 
dependent upon volume. In a high transaction volume system 
it is worth considering the possibility of splitting 
entities into sub-entities to reduce the volume in each 

set and perhaps even reducing the necessity for an 


access PATH. 
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ABSTRACT: 1)X is a program which allows the ordinary user to produce professional 
quality typeset output. ThX was developed by Donald E. Knuth of Stanford University and 
is currently used throughout the world for typesctting both technical and non-technical 
material. This paper will describe the use of TX and show some examples of its output. 
The transportable version of TEX, written in Pascal, has been successfully moved to the 
HP3000. The second part of the paper describes the tasks involved in this process. 


I. INTRODUCTION 


1. What is ThX ? 


Tau Epsilon Chi (T}X ) is a system for typesetting technical books and papers. It can 
also be used for ordinary non-technical material. The system does not require the user to 
have a knowledge of typesetting rules or conventions. © 

The original T)X system was developed at Stanford University by Donald E. Knuth. 
Frustrated in his attempts to print a second edition of The Art of Computer Programming 
in the same printing style as the first edition, he looked for alternatives in the area of 
computerized typesetting. Finding nothing that suited him, he embarked on a project 
which was to become the T,X system. This system is described in detail in his informative 
and humorous book, T}X and METAFONT [Knut79]. 

The T}X system is currently used throughout the world, partly for technical work in 
mathematics and physics, and partly for various other uses. The Journal of the American 
Mathematical Society now accepts ‘J\X input files for publication. Some major corpora- 
tions and universities use it for typesetting their internal documentation, user manuals, 
newsletters, etc. The I):X Users Group accepts articles and letters for their Journal in Tyex 
format. 


2. How does it work? 


The T}X program accepts an input file consisting of text and control sequences, and 
generates a device independent output file (DVI file) which contains commands for driving 
a raster printing device. Once ‘I}X has processed the input and produced a DVI file, it 
is up to a device driver program to interpret the commands in the DVI file and produce 
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printed output. This sequence of events is shown in igure 1. 













Device 


driver 
program 






typeset 
copy 






Device 


Figure 1. Functional diagram of the TjkX system. 


Most of the typesetting is done by TX automatically. TkX operates on many levels, 
composing pages, paragraphs lines and words. All of these are interrelated, with the 
intention of producing professional quality printing. In cases where TeX needs to be guided, 
for example in printing the TX logo, the user intervenes by specifying a control sequence 
(see 3. below). 

The TX system does not typeset a single word or a single line at a time. Rather, 
it typesets a page or more at a time. This is done for a variety of reasons. Mainly, we 
want the printed page to consist of pleasantly spaced paragraphs, lines and words. Also 
we want to avoid other unwanted phenomena, such as “widow” lines. A widow line is the 
first line of a paragraph appcaring at the bottom of a page with the paragraph continuing 
on the next page. To eliminate widows, T}X returns to the paragraphs already layed out 
and expands them slightly so as to use one more line on the page. This forces the widow 
line to the top of the next page. 

Paragraphs are composed to reduce the number of hyphenations and so as not to leave 
a single word stranded in the last line. In addition, the spacing between words is equalized 
throughout the paragraph. 

Lines of text are composed of words and other symbols (e.g. mathematical formulas) 
with the space between words equalized. 

Words are typeset with the letters placed one character width apart. Unlike stan- 
dard computer printers which print all characters in the same width (usually 1/10 inch), 
typesetting separates characters by the exact width of the character, depending on the 
“font” or character style uscd. In addition, TKX will place characters closer together or 
farther apart in accordance with traditional typesetting rules. For example, when typeset- 
ting the word “AVIATOR” the “A” and “V” are placed closer together; this is called 
“kerning”. Notice in the word “find” that the “f” and “i” are pushed together to form the 
“ligature” fi. These typesetting conventions and more are known to TX , freeing the user 
from having to memorize them. 

The basic concepts TycX uses are “boxes” and “glue”. A box contains something which 
is to be printed, and glue spccifies the spacing between boxes. For example, a character 
is a box, a word is a collection of character boxes, a line is a group of word boxes, a 
paragraph is a collection of line boxes, and a page is a box composed of paragraph boxes. 
The space between boxes can expand or contract by carefully defined amounts, called the 
stretchability or shrinkability of the glue. For example, when T)iX composes a paragraph 
that has a hyphenation it tries to back up and redistribute the spacing of the words in the 
paragraph to avoid the hyphenation. It does this by increasing or shrinking the space or 
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glue between the boxes by allowable amounts. 
For further details on the inner workings of TEX , see [Knut79] or [Spiv80]. 


3. Submitting an input file to TEX 


The input file for TgX is edited using any text editor. The text and any control 
sequences are contained in this file. When TEX is run, this file is designated as the input 
file. 


Basically, text is entered in a standard fashion with spaces between words, and one 
blank line between paragraphs. The input need not be formatted in any particular manner 
beyond this. Control sequences are defined as a “\” followed by a word or symbol. They 
allow the user to specify a special command. For example, “\it IMPORTANT” would cause 
the word IMPORTANT to be set in italic font. 


The TX system can be run in either interactive or batch mode. In interactive mode, 
if TyX finds an error the user is allowed to make modifications on the fly. For example, 


‘Undefined control sequence 
\iy 

IMPORTANT 
Tt 


The T\X program is indicating that it docs not know the control sequence “\iy” and 
shows what it has scanned on the first line, and what it has not yet scanned on the following 
line. At this point the user may correct the input by typing “1” to erase one symbol or 
control sequence, and then “I” to insert the correct sequence “\it”. Any corrections made 
in this manner are recorded in an errors file for future reference. 


As Tj:X is processing the input, it is writing to the DVI file. After the input is 
successfully processed, the DVI file is ready for the device driver program. 


Two other important facilities are available with TEX. These are alternate input 
files and macro definitions. Alternate input files are T}X input files which are read in 
conjunction with another input file. For example, if a paper has an abstract and three 
sections, and cach is in a separate file, a main file would draw them all together as follows: 


4% paper on TEX for the HP3000 

\input basic % basic control sequences 
\input texabs 4% abstract file 

\input sectl 

\input sect2 

\input sect3 

\end 


Each of the alternate input files could have had \input commands also. The maximum 
nesting depth is nine. 

Macro definitions allow the user to specify a common sequence by defining it and 
giving it a name. For example, the logo TX was specified by inserting “\TEX”. \TEX was 
previously defined as 
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\def \TEX{\hbox{lowercase{\:a \uppercase{T}\hskip-2pt\lower1 .94pt 
\hbox{\uppercase{E}}\hskip-2pt \uppercase{X}}}} 


It is much easier to write “\TEX” than to insert the above expansion. 


4. Fonts 


A font is a specific design of an alphabet and associated symbols. For example, this 
paper is set in a font called Computer Modern Roman. Most typewriters have Pica or 
Elite type fonts. The different “balls” or “daisy wheels” on some printers allow the user 
to change fonts. 

The TEX system allows up to 64 different fonts to be specified within the same job. 
A control sequence is given to switch from one to the other. Naturally you must have a 
device which can support all of these different fonts. 

Knuth also wanted to define his own fonts and created a system called METAFONT 
to do this. Using METAFONT one can design a font which is coded into a file for use by 
TX . For more information on METAFONT see [Knut79]. 


5. The DVI file 


The DVI file consists of a series of 8-bit codes which tells a device driver how to typeset 
the job. The format of the DVI files is given in Appendix B. 

Basically, 2 DVI file command is of the form “set the letter d and advance the character 
width” or “change to font 3” or “advance vertically 12 rsu’s”. No inherent intelligence on 
the part of the device is assumed. In fact, TEX gets along best with devices which have no 
internal programming, such as proportional spacing or typesetting firmware. 


6. Device drivers. 


The assumed printer is a raster scan printing device. This implies that all spacing 
between characters and lines is user specified. A typical computer line printer is not a 
raster device since it will always print 10 characters/inch, and six lines/inch (or some 
variation of this). Most of the daisy wheel terminals available now can be used as raster 
devices. The actual device TEX is aimed at is a commercial computer-driven typesetting 
device; such as a Xerox Graphics Printer, a Mergenthaler Linotron 202, or an HP2680 
Laser Printer. 

The TEX program has no knowledge of any particular printing device. It creates the 
same DVI file regardless of the output device. It is the job of the Device Driver program 
to interpret the DVI commands and produce output on a specific device. While there is 
only one TX program, there will be one Device Driver program for each output device. 


Il. TEX on the HP3000 


1. TEX in Pascal 


The TyeX system was originally written in a language called SAIL (Stanford University 
Artificial Intelligence Language). The SAIL compiler and the original TX system ran 
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on the DEC-20 computer only. T}X is in the public domain, but was not even remotely 
transportable. Due to the popularity of the system, a project was undertaken to translate 
the T)xX system into a computer language which was available on most modern computer 
systems. 

The language chosen for the transportable system was Pascal. The method for 
translating the system was as follows. First, a well documented pseudo-Pascal source was 
developed. This source has only a slight resemblance to a Pascal program and was intended 


to serve mostly as documentation, and to give all the algorithms. This file is often referred 
to as the DOC file. 


The second step was to produce syntactically correct Pascal source code from the DOC 
file. There is a program called UNDOC which performs this step. The resulting Pascal 
source is distributed anyone wanting to transport TrX to another computer. 

The DOC file is actually typeset, and a photocopy is provided with the distribution 
tape. The Pascal source is almost unreadable, but will compile. Examples of both of these 
files is in Appendix C. 


2. Moving TiX to the HP3000. 


The Stanford T)X-in-Pascal project brought the system to a point where it could be 
transported to other computer systems. The transportation process, however, requires a 
good deal of time and a patient systems programmer. 

At the time of writing, this author has successfully transported TEX to the HP3000. 
The project was by no means trivial, as will be shown. 

Bringing TEX to the HP3000 had a lot of problems right from the outset. First, there 
was no supported Pascal compiler at the time this project was begun. Second, the design 
of the TX program assumes a large address, space, something on the order of 600K words 
of addressable memory. 

The tasks broke down as follows: 

a. Edit the Pascal sources. While the system was translated to a “Standard” 
Pascal, there are still many variations and assumed extensions which had to be 
accounted for. With 23,000 lines of Pascal source this took considerable time and 
effort. 

b. Rewrite the “System dependent” routines. These are the procedures and 
functions which interface TEX with the file system, terminal I/O and other traits 
particular to the host system. About 25 routines had to be modified or rewritten. 

c. Implement a virtual memory scheme. ‘TX references several large arrays 
throughout, some as large as 50,000 elements with 4 32-bit words per element. An 
addressing scheme was developed to allow the array contents to reside in secondry 
storage. 

d. Revise the Pascal compiler to allow 32-bit integers and to compile large array 
references. TheX assumes 32-bit integers throughout, and the Portable P4 compiler 
from the HP Users Contributed library was modified to allow them. 


e. Optimize the performance of the system. When the above tasks were 
completed and the system first ran on the IIP3000, it was the incredibly slow. Where 
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the original ‘T}X system at Stanford processed a document in less than two minutes, 
the initial HP?3000 TeX took 40 minutes. By anaylzing TIHX's operation, some 
optimizations have been made reducing the run time to about 6 minutes. Additional 
optimizations will be made to allow the system to run as fast as possible. One tool 
which has been particularly useful for identifying inefficient code is APG /3000 from 
Wick Hill Associates. 


3. Device drivers. 


A device driver for a daisy wheel printer has been developed for use on the HP3000. 
While only one font is available at a time with this device, satisfactory results have been 
obtained. The output is suitable for internal documentation, and for proofing a document. 
Future plans are to develop a driver for the I1P2680 Laser printer. 


However, it is not necessary to have a high quality printing device on-site. There 
is one commercial printing house in San Francisco which uses ‘I)cX for typeseting on a 
Mergenthaler Linotron 202; the output from this device is camera ready. DVI files produced 
by TyeX on the HP3000, once proofed on the daisy wheel printer, will be sent to this 
commercial printer. 


U1. Conclusions 


This is a truly remarkable system. It gives the ordinary person the ability to print 
professional quality copy. The user will not have to explain to a typographer what is 
wanted, but will have personal control. 


The HP3000 implementation of T}.X will be a boon for any organization desiring to 
improve the quality of documentation, user manuals and other printed materials. Good 
results can be obtained with an inexpensive daisy wheel printer. Where camera ready copy 
is desired, several higher quality devices are commercially available. 


Hopefully more organizations will begin to use ‘I};X for documentation, manuals, 
annual reports and newsletters. Perhaps one day soon the HIP General Systems Users 
Group will accept papers for publication in T}.X format. 
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This is a real book. It gives a lighthearted introduction to the use of AMS-TEX, 
the version of TyeX used by the AMS. 
TUGhoat. The Ty:X Users Group Newsletter. Published by the American Mathematical 
Society. 
The T}X Users Group ts small currently, but enthusiastic and helpful. For 
information on membership write to 


TIX Users Group 

c/o American Mathematical Society 
P.O. Box 62-48 

Providence, Rhode Island 02910 USA 
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\noindent (\bf ABSTRACT3) \TEXN as a Program which allows 
the ordinary user to produce professional gquality 

‘pees output. 

\TEX\ was developed by Donald =. Knuth of Stantord 
University and is currently used throughout the world 

tor typesetting both technical and non-technical material. 
This paper will describe tite use of \TEY\ ana show 

some examples of its output. 2, . 

The transvortable version of THX, written in Pascal, 

has been successfully moved to tne H®300C. 

The secona part of the paper describes the tasks involvec 
in this process. 


\vskip 0.4 cu 
\noindent (\bf Ie INTRODUCTION) 


\vskip 0.3 ca 
\noindent (\bf 1. what is \TEXN ?} 


rhe da 0.1 cm — ; 
(\it Tau Sasilon Cni} (\TEXN ) is a system for typesetting 
technical pdooks and paperss, i 

Tt can also be used for ordinary non-technical material. : 
The systen does not require the user to nave a knowledge or 
typesetting rules or conventions. 


The original \TEX\ system was developed at Stanford University 
by Donala E. Knuth. : : 

Frustratei in his attempts to print a second edition of 

C\it The Art of Conputer Programming} in the same printing style 
as the first edition, he looked for alternatives in the 

area of eocputer izes typesetting. ; 

Finding nothing that suited him, he embarked on a project 


ABSTRACT: TEX is a program which allows the ordinary user to produce professional 
quality typeset output. TEX was developed by Donald E. Knuth of Stanford University and 
is currently used throughout the world for typesetting both technical and non-technical 
material. This paper will describe the use of TRX and show some examples of its output. 
The transportable version of TEX, written in Pascal, has been successfully moved to the 
HP3000. The second part of the paper describes the tasks involved in this process. 


I. INTRODUCTION 


1. What is TeX ? 


Tau Epsilon Chi (TEX ) is a system for typesetting technical books and papers. It can 
also be used for ordinary non-technical material. The system does not require the user to 
have a knowledge of typesetting rules or conventions. 


The original TX system was developed at Stanford University by Donald E. Knuth. 
Frustrated in his attempts to print a second edition of The Art of Computer Programming 
in the same printing style as the first edition, he looked for alternatives in the area of 
computerized typesetting. Finding nothing that suited him, he embarked on a project 


APPENDIX A. A portion of the TEX input file for this paper. 
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Command Name 


VERTCHARO 


VERTCHARI 


VERTCHAR127 


NOP 


BOP 


EOP 


PUSH 


POP 


HORZRULE 


Command Bytes 
Description 


0 
Set character number 0 from the current font such that 
its reference point is at the current position on the page, 


and then increment horizontal coordinate by the character's 
width. 


1 
Set character number 1, etc. 


127 
Set character number 127, etc. 


128 

No-op, do nothing, ignore. Note that NOPs come between 
commands, they may not come between a command and 
its parameters, or between two parameters. 


129 co[4] c1[4! ... ¢9[4] p/[4] 

Beginning of page. The parameter p is a pointer to the 
BOP command of the previous page in the .DVI file (where 
the first BOP in a .DVI file has a p of —1, by convention). 
The ten c’s hold the values of TEX’s ten \counters at the 
time this page was output. 


130 
The end of all commands for the page has been reached. 


The number of PUSH commands on this page should equal 
the number of POPs. 


132 

Push the current values of horizontal coordinate and verti- 
cal coordinate, and the current w-, x-, y-, and z-amounts 
onto the stack, but don’t alter them (so an XO after a PUSH 
will get to the same spot that it would have had it had been 
given just before the PUSH). 


133 

Pop the z-, y-, x-, and w-amounts, and vertical coordinate 
and horizontal coordinate off the stack. At no point in a 
.DVI file will there have been more POPs than PUSHes. 


135 h[4) w[4) 

Typeset a rule of height h and width w, with its bottom left 
corner at the current position on the page. If either h < 0 
or ¥ < 0, no rule should be set. 


APPENDIX B. DVI commands. 
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VERTRULE 


HORZCHAR 


FONT 


X2 


X3 


X4 


X0 


W2 


W3 


W4 


wo 


Y2 


134 b[4] w/4] | 
Same as HORZRULE, but also increment horizontal coor- 
dinate by w when done (even if h < 0 or w < 0). 


136 ¢(1] 

Set character c just as if we'd gotten the VERTCHARc 
command, but don’t change the current position on the 
page. Note that c must be in the range {0..127]. 


137 £[4) 

Set current font to f. Note that this command is not 
currently used by TEX—it is only needed if f is greater than 
63, because of the FONTNUM commands below. Large 
font numbers are intended for use with oriental alphabets 
and for (possibly large) illustrations that are to appear in a 
document; the maximum legal number is 227 — 2. 


144 m2! 

Move right mrsu’s by adding m to horizontal coordinate, and 
put m into x-amount. Note that m is in 2’s complement, so 
this could actually be a move to the left. 


143 m{3° 
Same as X2 (but has a 3 byte long m parameter). 


142 m4! 
Same as X2 (but has a 4 byte long m parameter). 


145 
Move right x-amount (which can be negative, etc). 


140 n(2} 

The same as the X2 command (i.e., alters horizontal coor- 
dinate), but alter w-amount rather than x-amount, so that 
doing a WO command can have different results than doing 
an X0 command. 


139 m{3] 
As above. 


138 m{4) 
As above. 


141 
Move right w-amount. 


148 n(2) 
Same idea, but now it’s “down” rather than “right”, so 
vertical coordinate changes, as does y-amount. 
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¥3 


Y4 


YO 


Z2 


Z3 


Z4 


Z0 


FONTNUMO 


FONTNUMI1 


FONTNUM63 


147 n{3} 
As above. 


146 n[4] 
As above. 


149 
Guess. 


152 m[2] 


Another downer. Affects vertical coordinate and 2-amount. 


151 m{3] 


150 m{4] 


153 
Guess again. 


154 
Set current font to 0. 


155 


Set current font to 1. 


217 
Set current font to 63. 
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95. Find the equation of the 
plane passing through the end points 
of the three vectors A = 3i—j-+k, 
B=i+2j}—k, andC =1+j+ 
k, supposed to be drawn from the 
origin. | 

96. Show that the plane 
through the three points (21, Yi, 21), 
(Xo, Y2, 22), and (x3, Y3, 23) is given 
by 

Zy—L Yi—y 

Lg—0 Y2—Yy 

Le Ya eee 
Solution. Let w = f(z,y,2z) = 
ec? + y? — z, so that the equation 
of the surface has the form 


i eee 
Le). 2), 


f(z, y, 2) = constant, 


APPENDIX D. An example of technical ty pesetting. 


12 VX: SYSTEM DEPENDENCIES . §36 


36. The procedure Print takes an integer as argument and prints the 
corresponding, strnypool entry both in the terminal and-in the errors file. 
procedure Prini(mes : integer); 
var t : integer; { index in the string } 
c: ascuCode; 
begin + := strng|mes]|; ¢ := strngpool|s]; 
while c < <> null do 
begin terOut] := chr(c); errfilt := chr(c); put(terOut); pul(errfil); 
Increment(1); ¢ := slrngpool|s] 
end; 
end; 
procedure /’rintLn(mes : integer), 
{ lake Print, but beginning at a new line. } 
begin terOulf :-= chr(carrsagereturn), errfilt := terOut]; pul(terOut), 
put(errfil); terOut| := chr(lincfeed); errful] := terOul]; pul(terOut); 
pul(errfil); Print(mes) 
end; . 
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APPENDIX C. Fragments of TEX DOC and Pascal source. 
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INTRODUCTION 


Scope 


This paper discusses general principles and specific 
techniques for making SPL and FORTRAN programs use less 


CPU time on HP3000 computers. 


There are three things which affect the CPU speed of a 


program: | 


(a) Hardware: Once one has purchased a particular 
machine, nothing can be done to increase its CPU 


speed. 


(b) Manufacturer-supplied compilers and run-time 
libraries: The quality of compiler-generated code 
can have a potent effect on the speed of a program, 
as can the efficiency or otherwise of the library 
routines it calls. Later sections of the paper 
highlight language features and compiler features 
which necessarily execute slowly, in order that the 


programmer might avoid them, where 


Ky y 


possible. 


Other features, where the necessity is 


improbable or dubious, are listed for temporary 


avoidance by the programmer until the suggested 


compiler enhancements are implemented. 


(c) User-written code: 


Given that suitable algorithms 


have been chosen, the way in which the user 


programs them can be of considerable consequence. 


Terminology 


To avoid much repetition, abbreviations are used for the 


names of the four main numerical data types, as shown 


below: 


Abbreviation 


SI 


LI 


SR 


LR 


Expansion 


short integer 
long integer 
short real 


long real 


SPL 
Equivalent 


integer 
double 
real 


long 


1.3 
1.4 
1.4.1 
FORTRAN 
Equivalent 
integer[*2] 
integer*4 1.4.2 
real 


double precision 
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Basis 


Statements made in this paper in relation to code 
emission by the compilers are based on the Athena (1918) 


software release. 


Timings were obtained on an HP3000 Series III. 


Background: The Machine Architecture 


It is of course stating the obvious to say that the 
HP3000 architecture, at the "machine instruction" level, 
is scarcely traditional. Many of the features of the 
machine ease considerably the task of generating machine 
code for medium-complexity languages such as SPL and 
FORTRAN. Some features however cause difficulty in 
emitting code, and this difficulty sometimes lead to 


suboptimal code. 


The low limits on direct data addresses (e.g. 
DB+255,Q+127) can cause problems with programs requiring 
many variables. This leads to an extra level of 
indirection in FORTRAN programs (see "MORECOM" and 
"Indirect Indirection” later) and surgery in SPL 


programs. 
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The BR (branch) instruction post-indexes (like all other 
memory-reference instructions) when it should pre- 
index. The code generated for computed GO TO, CASE and 
SWITCH statements is cute but is about 3 times as much 


as would otherwise be necessary. 


The elegant simplicity of the stack machine is rudely 

violated by the instructions which handle long reals. 1.5 
Far from the zero-address "stackops" used for arithmetic 

on other data types, these instructions operate on the 

addresses of one operand (negate), two operands 

(compare), or three operands (add, subtract, multiply, 

divide). Given this startling departure from 
orthogonality, togethér with the fact that there are no 
specific instructions for loading or unloading the stack 
four words at a time, the number of references to long 


reals in later sections of this paper should cause 


little surprise. 


The low limits on direct code addresses (e.g. 
P—255,P+255 for LOAD,BR,MTBA etc and P-31,P+31l for the 
test-and-branch instructions) cause two problems in code 


generation: 
(a) Is a branch to be direct or indirect? 


If indirect, where should the indirect word be 


placed? 
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(b) Where should constants be placed? 


Some solutions to these problems are good; occasionally 
however, an indirect branch is used unnecessarily, and a 
constant is dumped immediately (with a branch around it) 


instead of being carried forward. 


Background: The Compilers 


Neither the SPL compiler nor the FORTRAN compiler is 
represented by Hewlett-Packard as being an optimizing 
compiler. However, on perusing a check list of 
optimization techniques described in the literature, one 
finds that some of these are used (at least partially) 


and that the use of others is obviated by the machine 


architecture. 


It is generally accepted that of the languages available 
on the HP3000, SPL is the most "efficient", closely 
followed by FORTRAN. Looking at directly comparable 
features of the two languages, it is found that 
sometimes SPL generates better code, and other times 
FORTRAN does. Both compilers would benefit froma 


cultural exchange. 
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2.1 


GENERAL OPTIMIZATION PRINCIPLES 


Do it at compile-time 


While it may look better to code: 


PARAMETER PI = 3.14159... 


CIRCUM = 2.0 * PI * RADIUS 
(or the SPL equivalent) 


it will run faster if you write 


PARAMETER TWOPI = 6.28318... 


CIRCUM = TWOPI * RADIUS 


Neither compiler will simplify expressions involving 


constants; if you write 


A:= 1 +1; 


that is exactly what you get. 


Ze2 


Do it only as often as needed 


Both compilers perform limited elimination of common 
sub-expressions within a statement. This is done only 
with respect to subscripted array references. The 
seemingly wider scope stated by Splinter [1] 


(expressions in parentheses) does not prevail. 
The method used is to load the index register once only 
with the value required for the offset into the 


array(s). 


Three qualifications must be met for the compilers to 


perform this optimization: 


(a) The subscript expressions must be lexically 


identical. 


(b) The array(s) must not be long real. 


(c) (SPL only) The subscript "expressions" can only be 


simple variables or constants. 
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Examples of FORTRAN statements where the elimination is 


done are: 


A(I + J) = B(I + J) + C(I + J) 


D(I + 3, J + 5) = E(I + 3, J + 5) 
No elimination is done in: 
(not lexically same) 


A(I + J) = B(J + I) 


K = (I + J) * (I + J) (not in array reference) 


Where there are common sub-expressions not fitting the 
aeaue criteria, time and code-space can be saved by 
using a temporary variable. 

Invariant expressions can be moved outside loops. This 
seems obvious, almost too trivial to mention, but such 
cases can be "hidden" by the high level language: see 


section 3.1.1. 


Do it in the registers 


The HP3000 architecture does not offer quite the same 
scope (or the necessity!) for optimizing the use of 
registers as does a machine of the "umpteen general 


purpose registers" variety. 
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The index (X) register has a limited arithmetic 
capability, and may also be used as temporary storage. 
Of course the X register is used for several things 
other than array subscripting, and so it is dangerous to 
merely equate some name to the X register and write code 


as though an ordinary variable was involved. 


In particular the use of the X register in and around 


Statements involving long reals is perilous. 


E.g. LONG A, B; 
LONG ARRAY C(0:10), D(0:10); 


INTEGER X = X; 


ec #2 © 


A:= B; << SETS X TO 1 
IF B IS A PROCEDURE ARGUMENT BY 
REFERENCE> > 

C(X):= D(X); << CHANGES VALUE OF X >> 


The assignment operator can be used in SPL to replace a 
load from memory with a faster stack-duplicate 


operation, 
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2.4.1 


10 


Instead of 


C:= D+ &; 
A:= B + C; 
write 


Warning: for long reals, the compiler generates worse 


code for the Latter case. 


Don't do it at all 


When you write 
FOR I: 


STEP K UNTIL £& DO ..... 


the SPL compiler must generate code which checks whether 


the loop is to be entered at all. 


When you write 


FOR I:= 0 UNTIL 9 DO ..... 
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Ll 


the loop body must be entered, but the compiler still 


goes through the motions. 


If this latter loop is nested within others, this is a 
waste of time, which can be saved (together with 2 or 3 


words of code) by writing 


FOR®: Des7 0a dae 


Don't do it with a procedure call 


As is well known, there is a reasonable overhead 
involved ina call to a procedure in the current 
segment, and a greater overhead in a call to a procedure 
in another segment (especially if the called segment is 


not present in memory). 


While splitting a program into procedures or subroutines 
aids greatly in structuring a program, care should be 


taken to avoid frivolous procedure calls. 
The SPL subroutine, although offering a somewhat more 


austere environment than a procedure, has the advantage 


of faster invocation and faster return. 
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It may sometimes be worth the waste of code space to 


change a procedure into a subroutine and include it in 


each calling procedure. 


The following "dirty trick" allows a single copy of a 


subroutine to be shared by several procedures in the 


same segment: 


(a) Include the source of the subroutine ("SHARED'SUB") 


in an “initialising" procedure. 


(b) The initialising procedure should include: 


SUB'ADDR:= @SHARED'SUB; 


where SUB'ADDR is global. 


(c) Invocation of the shared subroutine is done by 


<< stack arguments, if required >> 
TOS:= SUB'ADDR; 


ASSEMBLE (SCAL 0); 


Lig Dao Less obvious than explicit procedure calls (coded by the 


programmer) are implicit procedure calls generated by 


the compilers. 
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Usually there is a rationale for an implicit procedure 
call: the language feature is not directly supported by 
the microcode, and in-line code would take up too much 


space. 


In Fortran, all "basic external functions" are handled 
by procedures. Turning to the "instrinsic functions", 
which also look like function calls at the source level, 
we find that some of them are in fact handled by in-line 
code. Almost all the numerical functions are in this 
category; among the exceptions are AINT, JDINT, DDINT, 


AMOD, and the MAX/MIN family. 


Of course the MAX and MIN procedures cater for a 
variable number of arguments; but there is a case for 
using in-line code for the frequent case of two short 
integer arguments. The code currently generated for 


J = MAX (K, L) is 


LOAD K 
LOAD L 
LDI 2 
PCAL MAX0' 
STOR J 
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whereas in-line code would take only two more words: 


LOAD K 
LOAD L 
DDUP, CMP 


BGE P + 2 


XCH, NOP 
DEL, NOP 
STOR J 


In a degenerate case such as J = MAX (K, J), the 


programmer can instead write 


IF (J.GT.K) J = K 


which is better than the in-line code above, especially 


if the probability of J exceeding K is low. 


In both SPL and FORTRAN, procedures are generally used 
for exponentiation. The exception is that FORTRAN emits 
in-line code for the exponentiation of short integers 
and short reals to the short integer powers 1, 2, 3 and 


4. 


<4 


This means that, cont-ary to the advice given by H-P 
[3], it is better to write A**2 than A*A, where A is 
short (integer or real). The converse applies when A is 


long (integer or real). 


It is curious that optimization of the unlikely 
expression A**1l is done (not very well: B = A**] 


generates e.g. 


LDD Q + 1, I; NOP, NOP; STD Q + 2, I) 


whereas no effort is made with the equally unlikely 


expression A**0Q. 


Be wary of long reals 


As mentioned earlier, the non-stack nature of the 
instructions for handling long reals makes life nard for 
compiler writers, occasionally leading to the emission 


of rather peculiar code. 


In the code generated for A = B + C, the FORTRAN 
compiler loads the address of A last instead of first, 
then does CAB, CAB to put it into the right place. The 


SPL compiler avoids this waste of time and code space. 
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The FORTRAN compiler always uses the MOVE instruction 
for simple assignments, and usually achieves reasonable 
code, e.g. nine machine instructions for A(J) = B(J). 

On the other hand the SPL compiler eschews the MOVE 
instruction and in desperately trying to simulate 4-word 
loads and stores, requires 22 instructions to encode 


A(J):= B(J)!! 


As the long real machine instructions work with 

addresses, not values on the stack, it follows that when 
expressions force the compilers to put temporary results 
on the stack (the natural method with other data types), 


the results will be sub-optimal. 2.7 


One way of avoiding this is to use variables to hold 2.7.1 


often used constants. 


It is better to write 


ONE = 1D0 
A= A + ONE 2.7.2 
B= B + ONE 
than 
A= A + 1D0 
B= B + 1D0 
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Another method is to simulate the code which would be 


emitted by a compiler for a 3-address machine: 


Instead of 


write 


TEMP 


Cc * DD 


= B + TEMP 


Avoid data-type conversions 


Unlike SPL where the programmer must explicitly code a 
type conversion, FORTRAN automatically emits type 
conversions in "mixed-mode" expressions. As these 
conversions take time and code-space, they should be 


avoided where possible. 


Particularly wasteful is the habit common to some 
programmers of using short integer constants in an 
otherwise real expression. The code generated by 
A= A + 1 runs at about 70% of the speed of that 


generated by A=A + 1.0. 
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Conversion from long integer to long real and vice versa 


requires a procedure call; all others are done in-line. 


Intriguing code is generated by the FORTRAN compiler for 


the conversion from long integer to short integer. 
The instructions used to do it on the stack are: 
DTST, NOP 

DASL 16 

DEL, NOP 

followed by a test for overflow which is not done in 
SPL. The SPL compiler uses only one word of code 


instead of the 3 above: 


DTST, DELB. 


Multiply instead of dividing 


Multiplication is faster than division, so it should be 


substituted where possible. 


2.8.2 


Care should be used when replacing division by 
multiplication when a constant i% involved. ‘or example 
10.0 can be represented exactly as a short real, but 0.1 
Cannot be. Coding A=B*0.1 instead of A=B/10.0 may 


result in loss of precision. 


Exploit special hardware features 


Testing for a true or false value is actually reduced by 
the machine to a test for odd or even. Consequently we 
may obtain a test for parity in the guise of a "logical" 


test. 


In SPL, the condition 


I MOD 2 1 
can be re-written as 


LOGICAL (T) 


and in FORTRAN, the similar condition can be re-written 


as BOOL (I). 
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2.9.4 
In SPL the construct I <= J <= K uses the CPRB (compare 
range and branch) instruction and it is better to use 
this than 
I <= J AND J <= K. 
However, when the lower bound is zero, it is much faster 
to use 
LOGICAL (J) <= LOGICAL (K) 
than 0 <= J <= K. 
The hardware condition code is not affected merely by 
testing it, nor by branches. Where a logic path is 
required for each of the results of a comparison 
(<, +, >), the test does not need to be performed twice. 
Instead of 2.10 


IF I = J THEN ... 
ELSE IF I > J THEN ... 


ELSE ...; 


write 
IF I = J THEN ... 
ELSE IF > THEN ... 


ELSE ... 
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The CMPB (compare bytes) instruction can be induced to 
report the residual count of uncompared bytes, as well 
as the addresses of the unequal bytes and the condition 


code. 


A classic case is scanning off trailing blanks. 


Although it is easier and clearer to write 


WHILE LEN > 0 AND BUF(LEN-1) = " " DO LEN:= LEN-1; 


the following code runs much faster: 


IF BUF(LEN-1) = " " THEN BEGIN 
IF BUF(LEN-2) = BUF(LEN-1), (1-LEN), 0 THEN; 
LEN:= - TOS; 
DDEL ; 


END; 


Avoid unnecessary memory references 


The standard practice of the FORTRAN compiler and the 

normal usage of the SPL programmer is to address arrays 
indirectly through a pointer. To obtain the contents of 
an array element, the contents of the pointer cell must 


first be obtained. 
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2.10.2 


2.10.3 


22 
ce 
The SPL programmer can avoid this, when sufficient 
primary address space is available, by coding "=DB" or 3.1 
"=Q" in the array declaration. As only the "zero'th" 
element of the array must be in the direct address 3.1.1 


range, one large array may use direct addressing. 


The FORTRAN compiler makes no attempt to use direct 
addressing, even in the simple case when all the local 
arrays and variables would fit in the range 


(Q+1, Q+127). 
Although optimal allocation of addresses might require 


n! iterations where n is the number of local arrays and 


variables, some optimization would be better than none. 
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OPTIMIZATION TOPICS SPECIFIC TO FORTRAN 


Multi-dimensioned arrays 


Given the declaration 


DIMENSION A(3, 4, 5), AX(60) 


EQUIVALENCE (A, AX) 


when the programmer writes 


DO 100 K =1, 5 


100 T=T+A(I, J, K) 


the effect is as though the following had been written: 


DO 100 K=1, 5 


100 T=T + AX(((K - 1) * 4+g9- 1) * 3 + TI) 


Obviously part of the offset calculation need be done 


once only, before the loop is entered. 


It is possible to recode this as: 


IX =(J- 5) * 3 +I 


DO 100 K = IX + 12, IX + 60, 12 


100 T=T + AX(K) 
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3.1.4 
Such rewriting is of course error-prone. Having the 
compiler do it would be preferable, but this is one of 


the more complex optimization algorithms. 


Where one or more of the subscripts is a constant, no 
cognisance is taken of this, and the effect is 
ludicrous. For example, when the user writes 


A(1, 1, 1), the code emitted is as though he had written 


AX(((1 - 1) * 4 41-1) %* 3 +21) 


instead of AX(1)!! 


There is a glaring need for compiler enhancement in this 


case. 


The programmer should evaluate carefully his perceived 3.2 
need for multi-dimensioned arrays. Often such an array 
can be replaced entirely by an array of one dimension, 3.2.1 
or an array of one dimension can be equivalenced to it 

and used for some of the manipulations required 

(especially those which operate on every element of the 


array). 
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One special case is where an array has two dimensions, 
but in references to the array, one of the subscripts is 
always constant. This array should be split up into 


several arrays of one dimension. 


For example: 


DIMENSION CASH(3, 10) 


NET = CASH(1, J) - CASH(2, J) - CASH(3, J) 
is better written as: 


DIMENSION SALES(10), EXPENSES(10), TAX(10) 


NET = SALES(J) - EXPENSES(J) - TAX(J) 


This is much clearer as well as much more efficient. 


MORECOM 


As mentioned earlier, the limit of 255 on direct 


DB-relative addressing causes problems with FORTRAN 


programs with many variables and arrays in COMMON. 


The compiler option $CONTROL MORECOM was introduced to 


alleviate this problem. 
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When this option is in effect, instead of one word of 
primary DB being allocated to point to each variable and 
array in COMMON, one word is allocated to seine to each 
COMMON block. Consequently indexing must be used to 


address variables within- COMMON. 
Assume the following declarations: 
REAL A, B, C 

INTEGER I, J 


COMMON/BLK/I, A, J, B 


Without the MORECOM option in effect, the statement 


C = B will generate code such as: 


LDD DB + 3, I 


STD Q+l 

which is as good as one will ever get. 

With MORECOM, HOWENGE the same statement will generate: 
“LDXI 2 


LDD DB + QO, I, X 


STD Q+il 
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The variable B above is at an even offset (4) From the 
Start of the hlock - this allows the use of double-word 


a. 


indexing in the LOND instruction. 


Things can be worse: the variable A is at an odd offset 


(1) from the start of the block - what happens is this: 


LDXI 1 

LOAD DB + 0, I, X 
INCX, NOP 

LOAD DB + O, I, X 
DTST, NOP 

STD Q+1 


To add insult to injury, the DST instruction above is 


quite redurdant. 


A similar effect is observable when arrays av: wed; 
however when the offset is zero, the (longer) «-«de for 
the odd case 1s used!! 

Timinus ace shown below fer repeating A(I) = BI) 5,000 


times, where A and B are REAL arrays. 
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Addressing for Time Ratio to 3.3 
A & B (ms ) "standard" 
3.3.1 
No MORECOM 56 1.00 
MORECOM,offset even,>0O 90 1.61 
MORECOM,offset odd 154 2.75 


With one-word variables and arrays (INTEGER*2, LOGICAL) 
and four-word variables and arrays (DOUBLE PRECISION), 
the parity of the offset is irrelevant; it just takes 


more code and more time when the MORECOM option is used. 


When the use of the MORECOM option is unavoidable, 
considerable time and code space can be saved by 
ensuring that the offsets of REAL and INTEGER*4 
variables are even. A straightforward way of doing this 
is to list all the REAL and INTEGER*4 variables and 
arrays first in the COMMON statement. Offset parity in 
existing COMMON blocks can be checked by perusing the 


output of the compiler MAP option. 


A better solution would have been to allocate two 
DB-primary words per common block, one pointing to the 
lst word in the block and the other to the 2nd word. 
Thus any offset in the block would be even with respect 
to one of the pointers. Unfortunately this would have 


restricted the maximum number of common blocks to only 


127 instead of 254! 
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S INTEGER* 4 


As the manual says, this option forces all integer 
variables and arrays (other than those explicitly 


declared INTEGER*2) and all integer constants to be 


INTEGER*4. It is likely to be used in the early stages 


of converting a FORTRAN program from another machine. 


Use of this option can cause gross waste of code space 
and data space and considerable increase in execution 


time. 


Consider the following example: 


REAL A(10), T 
T = 0.0 
DO 100 I = 1, 10 


100 Te=T + A(L) 


Without the use of the option, the variable I and the 
constants 1 and 10 are INTEGER*2, and the loop is 
controlled by the efficient MTBA instruction which 
increments I, tests it against 10, and branches back to 


the start of the loop, all in one hit. 
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When SINTEGER*4 is in effect, I, 1 and 10 are INTEGER*4, 
and the loop is controlled by code which is slow for t o 


reasons: 


(a) each function of the MTBA instruction has to be 


simulated separately 


(b) LI arithmetic is slower than SI. 


Once a converted program has been made to run correctly, 


the following steps should be taken: 


(a) Remove the SINTEGER*4 


(b) Insert IMPLICIT INTEGER*4 (I-N) 


(c) Determine which variables and arrays do not need to 


be INTEGER*4 and declare them explicitly as 


INTEGER* 2. 


(d) Determine which constants need to be INTEGER*4 and 


append the letter "J" to them. 
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Character Variables 


The following declarations are used in the discussion: 


CHARACTER A*80, B*1(80), C*(10), D*10 
EQUIVALENCE (A, B, C), (B(1l1), D) 
INTEGER*2 I, J, N 


CHARACTER S*(N), T*1, U*1 


The code generated for references to character variables 
of constant size (e.g. A), and for references to 
constant substrings (e.g. A [11:10]) is generally 


efficient. Some special cases are: 


(a) Assignment o1 character variables of size 1 is done 
by the same sort of code as is used for wider 


variables. 


E.g. T = U is done by 


LOAD Q+1 


LOAD Q + 2 


LDI 1 
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instead of 


LDB Q+ 2, I 


STB Q+1,/I1 


and T=" " is done by 
LOAD Q + 1 

BR P + 2 

020000 

LRA P- 1 

LSL 1 

LDI 1 

MVB PB, 3 


instead of 


LDI 


$40 


STB Q+1,1 
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(b) When a shorter string is assigned to a longer 
string (e.g. C = T), the balance of the longer 
string is blanked by calling the procedure 
BLANKFILL'. If one really needs the blanking done, 


an alternative is: 


I 
3 


Cc [1:1] 


Cc [2:9] 


This will run faster, but takes more code, and if 


one counts too few blanks, BLANKFILL' will still be 


called! 


(c) When the position part of the substring is not l, 
code must be saieeea to generate the offset from 
the start of the variable. Thus it is faster to 
use D than A[11:10]. The offset is calculated once 
only (using rather cunning code) in the subprogram 


prologue; the trade-off is the extra word taken for 


a pointer to the start of D. 


3.4.3 If the size of a string is variable (e.g. S), or 
variable substrings are used (e.g. A[I:J]), external 
procedures are used not only to perform the operation 


required, but also for paternalistic error checking 


which cannot be turned off. 
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Where only the position part of a substring is variable 
(e.g. A [1T:10)), it may be possible to avoid the dreaded 
PCALS by equating to a character array. §&.g. it is 


better to use B(I) than A[I:1l]. 


When reference is made to a character array of more than 
one dimension, the element offset is calculated as 
described in Section 3.1.1; then this is multiplied by 
the element size to get the byte offset. (The 
multiplication uses slow unsigned arithmetic (LMPY, 
DELB), because the byte offset could exceed 32K). Thus 
offset calculation for a character array of n dimensions 
is as complicated as that for an integer (say) array of 
n + 1 dimensions. The exception is where the character 


element size is 1; multiplication by 1 is avoided. 


Indirect Indirection 


A Fortran main program or subprogram can run more slowly 


than expected if it has many local variables. 
All local variables and arrays must be addressed 


relative to the Q register, and the direct range is +1 


to +127. 
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Space in this range is allocated according to the 


Following priorities: 


(lL) One word as a pointer to each array, character 
variable or variable mentioned in a DATA statement 
(Compilation will fail if there are more than 127 


words required.) 


(2) One word for each INTEGER*2 and LOGICAL variable, 


(3) One word as a pointer for each DOUBLE PRECISION 


Variable. 


(4) Two words for each INTEGER*4 and REAL variable. 


Once the total of the above allocations exceeds 127, one 
location (typically Q +1) is allocated as a pointer to 
an "extension area". Then the remaining variables are 
addressed as though:the extension area were an array and 
they were elements of the array. The offset into this 
pseudo-array is shown in the output from the compiler 


MAP option. 


The effect on the execution Speed is apparent from the 


code generated: 
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Variable J's address in the MAP is Q + 23. 


The code required for J = 0 is 


ZERO, NOP; STOR Q + 23. 


Variables K's address in the MAP is Qt+l1, I, $%ll. 


The code required for K = 0 is 


ZERO,. NOP; LDXI %11; STOR Q + 1, I, X. 


Fortunately the problem does not seem to be compounded 

by parity problems with REAL and INTEGER*4 variables (as 

it is with MORECOM); there is no language-imposed 3.6 
ordering requirement (as there is with variables in 

COMMON) and in observed cases the compiler allocates the 

two-word variables first, so that they are at even 


offsets in the pseudo-array. 


Unfortunately when some variables will fit in the 

primary area and others would not, the compiler has no 
way of knowing which will be used more frequently than 
others, so it can happen that a variable used as a DO 


index can end up in the secondary area. 
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Several things can be done by the programmer to 


alleviate the problem: 


(1) Split the subprogram. 


(2) Use EQUIVALENCE to equate less frequently used 


variables to elements of arrays (one array for each 
data-type). 
(3) Put some variables into COMMON. If MORECOM is 
required, the less frequently used variables should 
be put into COMMON. While this is the easiest to 


write, it will typically waste stack space. 


SCONTROL BOUNDS 


Use this option, if you must, while debugging, but be 


sure to remove it for production running. 


This option generates a procedure call for each 


subscripted array reference. 
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The Formatter 
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We have the authority of Splinter [1] saying that the 

implementation of the Formatter is inefficient; on top 

of this it should be realised that each READ or WRITE 

Statement involves an overhead of two procedure calls, 3.9 
together with one procedure call for each variable, each 


array, and each iteration of a DO-implied list. 3.9.1 


Unformatted I/O merely avoids the conversion to external 
form; it does not avoid all those procedure calls. It 
is often worth the effort involved in using the file 


system instrinsics instead of unformatted I/O. 


Further details on the diseconomy of using the Formatter 


are given by Green [4]. 


SCONTROL INIT 


Use of this compiler option causes all local variables 
and arrays to be cleared to zero during the subprogram 
prologue. The code used to do this is quite 
efficient: one block move is done to clear variables 
and arrays with fixed bounds, and another is done if 


there are any arrays with dynamic bounds, to clear them. 
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It follows that if any arrays, or more than a few 
variables, are to be cleared at the start of a 
Subprogram, it is much better to use SCONTROL INIT than 


to write explicit statements, especially for the arrays. 


Use of SPL Routines 


SPL allows access to all the features of the machine, 
and can thus be used to perform operations which can be 
expressed only clumsily, if at all, in FORTRAN. As 
access to an SPL routine from FORTRAN necessitates a 
procedure call, the time saved within the SPL routine 


needs to be worthwhile. 


As recommended in [3], a frequent choice for an 
excursion into SPL ie usage of the MOVE and MVB 
instructions for initializing or assigning arrays en 
masse. Appendix A shows an example of how to obtain 


leverage from the investment in a PCAL by allowing many 


arrays to be cleared at once. 
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MISCELLANEOUS ae ewe 
Slow programs: prevention 
Ensure that the best data structures and algorithms have 
been chosen; it is pointless to “bit-twiddle" with the x 
register if you are bubble-sorting a 10,000 element 
array. 
When writing the program, bear in mind the language 
features which can cause a problem, and avoid them in 
frequently executed code. 
4.2.3 


Draw a diagram showing which procedures call which other 
procedures, and arrange the segmentation to minimize 


calls which cross segment boundaries. 


Slow programs: cure 


Obtain a PMAP of the program and establish the reason 
for each external procedure reference. This should be 
easy for procedure names which do not contain an 


apostrophe: you explicitly coded the procedure call. 
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However procedures whose names contain an apostrophe are 
likely to be called implicity by the compiler. The 
Compiler Library Manual will give you an idea of what 
the procedure is for. The PMAP will tell you one 
subprogram in each segment which is calling the 
procedure. If you still cannot match up the procedure 
name with the language feature it encodes, it is 
possible to decompile the calling segment, find the 
actual references, and tie these back to the source (via 
the PMAP and the LOCATION output of the compiler). 


Then, if desired, the source can be modified to avoid 


the procedure call. 


If the problem cannot be traced to one or more external 


procedure calls, several options are open: 

(a) Review the segmentation 

(b) Read your source again carefully. 

(c) Ensure debugging statements are in-operative. 


(d) Re-run the program with calls to e.g. PROCTIME 


inserted at salient points. 
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Know your aachine 


For high-lLavel-lanyguage progcaamers interested in 
learning more about what happens behind the scenes, 4 
starting point is to read sections of the Syst 


Reference Manual. 


This will give an overview of how the machine works at 
the machine code level. The Machine Instruction Set 
Manual should be used as a reference for particular 


machine instructions. 


Specific details as to the implementation of Language 
features can be obtained by compiling sample source 
programs with the MAP option (and, for FORTRAN, the 
LOCATION option), prepping with the PMAP option, and 
then decompiling the object program. The programs 


DECOMP (in the Contributed Library) and EMMISASM (on the 


Orlando swap tape) may be used for this purpose. 


The INNERLIST option in the SPL compiler is often 
useful; however as its output is produced before code 
generation is complete, the result can occasionally be 


misleading. 
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Fature shock 


AS shated in section 1.3, this paper is based on 
opservation of the behaviour of the Athena versions of 
the SPL and FORTRAN compilers. It is hoped that future 
versions of the compilers will generate better code. It 
is Likely that when an enhancement is made, the code 
generated by the compiler for a particular language 


feature will be better than that generated for the 


"work-around" the programmer has used in the interim. 


It may be found useful for the programmer to set up a 
jobstream to compile, prepare, and decompile a program 
(or suite of programs) which exercise the language 
Features and their work-arounds. This jobstream may 


then be run after a software update and its output 


compared with previous results. 
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APPENDIX A: CLEARMANY PROCEDURE 


Purpose 


This procedure will clear one or more arrays with one 


call. 


Calling sequence 


Given that n arrays are to be cleared: 


The (2i-1)th argument is the address of the ith array. 
The (21)th argument is the number of words to be cleared 
in the ith array. 


The (2n+1)th argument is n, the number of arrays. 


Limits: 1 <= n <=29 


Example: 
INTEGER*2 SIA(100), SIB(M) 
DOUBLE PRECISION LR(10,10) 


CALL CLEARMANY (LR, 400,SIB,M,SIA(51),50,3) 
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Warning: 


The PORTRAN compiler will complain if there ace two oc 


moce calls in one subprogram and the arguments do not 


agc2ze in type and number. 


Source 


Procedure clearmany (n); 
integer n; 
begin 
integer fence, i; 
integer pointer arg, len, block; 
instrinsic quit; 
<<start of argument checking>> 
if not (l<=r <=29) then quit(1); 
pus’ (Q); 
fence:= tos-5-2*n; 
@arg:= @n; 
for* is= 1 until n do begin 
@arg:= @arg-2; @len:=arg(1); 
if logical(arg) > logical(fence) then quit (2); 
i€ logical(@len) > logical(fence) then quit (3); 
if not (1l<= len <= (fence-arg-1)) then quit (4); 
end; 


<<end of argunent checking>> 
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@arg:=@n; 
for * i:= 1 until n do begin 
@arg:=@arg-2; 
@block:= arg; 
@len:= arg (1); 
block: =0; 
move block(1):=block,(len-1); 
end; 
tos:= $31400 + 2 * n +1; 
assemble (XEQ 0); 


end; 
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INTRODUCTION 


Motivation 


The "software crisis", which has been generally recognized in the last 
ten years, has created the need for tools that allow programmers and users 
of computers to be more productive. The traditional tools (compilers, 
editors, file systems, etc.) are not adequate to keep pace with the grow- 
ing power of computers and the expectations of those who use and pay for 
them. 


Consequently, the past few years have seen a multitude of products 
introduced which claim to improve programmer productivity or, ina few 
instances, eliminate the need for programmers, or at least coders. Spec- 
ifically, in the HP/3000 product line, Image, Query, DEL, KSAM, and V/3000 
have been introduced by HP. Outside vendors have added to this list with 
products which, while frequently improving on the HP products, are more 
imitative than inovative. For example, there are several "Query like" 
products available from independent vendors which extend the functions 
of Query and remedy several of its obvious deficiencies, but do not offer 
a fundamentally different kind of tool. 


More recently, several inovative tools have appeared on the market. 
Among these are two relational database management systens,. Relate/3000! 
and Rel*Stor. The inovative aspect of these products is that they are 
based on the relational model rather than the network model of Image. 


Objectives 


The purpose of this paper, and the study on which it is based, is to 
compare these products with Image both in concept and implementation to 
determine the strengths and weaknesses of each. The goal is to select one 
of the three as the basis of further development of software tools. 


The authors do not presuppose that one of these products will be 
clearly superior to the others or that one would be the best choice under 


all circumstances. However, this study should serve as the basis for a 
rational decision. 


Scope 


To do a thorough analysis of these products, one should probably use 
each for a year or more in a variety of applications. Since this is not 
feasible, the authors have elected to evaluate them on the basis of: 

1. The published specifications and user manuals; 


2. The mapping of a small, but demanding database onto each system; 


3. Performance on the HP/3000 as indicated by carefully ci..se: ‘este. 
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This analysis is further complicated because: 


1. Both Rel*Stor and Relate/3000 are still under development with modules 
and features not yet implemented; 


2. Their manuals are likewise under development, and not always in step 
with the product; 


3. One product (Rel*Stor) was not made available for testing. 


Therefore, the reader should be cautioned not to accept this study as 
the last word on these products. 


Database Models 


BACKGROUND 


Most authors*~’ list three different models for databases. These are 
idealized models of how data is naturally structured and do not consider 
questions of implementation or efficiency. Rather, the models are based 
on mathematical principles. 


These three models are known as the network model, the hierarchical 
model, and the relational model. Virtually all database systems are based 
on one of these three models. Moreover, an important step in designing a 
specific database is modeling it in one of these three forms. 


Each form has its own peculiar strengths and weaknesses. These are 
discussed briefly below. One problem found in discussing models and data- 
base systems is that each, generally, has a unique vocabulary. This is 
confusing enough when considering them one-at-a-time. When three models 
and three systems are discussed in one paper, it is hopeless. Therefore 
a "generic" vocabulary will be employed here as listed below. The authors 
apologize to those who may find these terms imprecise or contrary to 


standard usage: 


Entity 


Attribute 


Field 


Record 


Key 


an object or "thing" about which information 
is stored in a database. 


a characteristic of an entity. Only attributes 
of an entity can be stored, not the entity itself. 


the physical representation of an attribute. 


the physical representation of an entity consisting 
of the fields that hold the attributes of that entity. 


a set of attributes that distinguishes one entity 
from other similar entities. 
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File 


- the physical representation of a group of similar 
entities consisting of the records representing 
those entities. 


Relationship ~- a logfeal connection between entities. For example, 


between a parent and children, or between a vendor and 
purchase orders to that vendor. 


The adjective "logical" will be applied to the terms field, record, key, 
and file when discussing the corresponding parts of the models. 


A "standard" database problem will be used as an example throughout the 
remainder of this paper. This problem is a simplified accounting system. 
The entities and their attributes are as follows: 


Entity 


Department 


Expense 


Account 


Transactions 


Attributes 
Dept # - a unique number assigned to each department. 
Dept name - the common name of the department. 
Dept head - the name of the manager of the department. 
Exp # - a unique number assigned to each expense type. 


Expense description - a description of the expense 
type. 

Account # - a unique number assigned to each account, 
consisting of a dept # concatenated with an expense 
number. 


Budget amount -— the dollar amount budgeted for this 
account. 


YTD credit amount - the total dollar amount of all 
transactions credited to this account. 


YTD debit amount - the total dollar amount of all 
transactions debited to this account. 


CR Account # - the number of the account to which this 
transaction is credited. 


DB Account # - the number of the account to which this 
transaction is debited. 


Amount - the dollar amount of the transaction. 
Date - the date of the transaction. 


Reference - the account reference of the transaction. 


Network Model 


The network model is characterized by logical files, each of which 
represents an entity type. The logical files are connected by relation- 
ships that show how entities in one logical file are related to entities 
in other logical files. 


The relationships are usually restricted to one-to-N or 1:N types. 
This means that exactly one entity in one logical file is related to 
N(zero or more) entities in another logical file. This is customarily 
noted by an arrow pointing from the "1" entity to the "N" entity. For 
example, a department entity may be related to many accounts while an 
account entity must be related to exactly one department. 


More than one relationship may exist between two entities. For 
example, each transaction is related to exactly one account as a "credit 
account" and to exactly one account as a "debit account.” This is done as 
two 1:N relationships from account to transaction. 


A convenient way to represent a network model is by a "data structure 
diagram." Such a diagram is shown in Fig. 1 for the accounting problen. 


Note that entities are usually linked together by a shared attribute value. 


The name of the shared attribute is shown on the arrow in the diagram. 
The underlined attributes are keys. 
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Notice that some of the attributes appear in parentheses. These are 
the same attributes that are used for the relationship linkage. Thus, 
it is redundant to show them as attributes; however, this is done in 
parenthesés for logical completeness. 


The network model.is probably the most general of the three models. 
The network formed by the relationships can take on any topography and 
the links show the entity relationships. The other models are more 
restrictive. 


Hierarchical Model 


The hierarchical model is, structurally, a subset of the network model; 


i.e. any hierarchical structure can be built under the rules of the network 


model. The difference is that additional constraints are imposed on the 
hierarchical model. These have to do with the relationships between enti- 
ties and are as follows: 


1. There is a unique entity type called the "root" where the hierarchical 
network begins. 


2. Each entity, except those in the root, has exactly one “parent.” A 
parent is another entity of a different type at a higher level. 


3. Each entity, except those at the lowest level of the hierarchy, may 
have multiple "children." A child is another entity of a different 
type at a lower level. 


The account example does not map easily into the hierarchical model 
because both the "account" and “transaction” entities have multiple parents. 
A better example is the bill of materials problem shown in Figure Zz: 


Automobile 
‘ ‘ ansmissioan Rad 
Block Head Accessories pats Pain m 
Figure 2 
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The hierarchical model is rightfully popular in situations where the 
data is naturally hierarchical. Otherwise, most of its usage seems to 
result from the dominance of several early database management systems 
based on this model. Many problems, including our elementary accounting 
example, would require unnatural restructuring to fit this model. 


Relational Model 


While the network and hierarchical models are similar to each other, 
the relational model is totally different from them. The database con- 
sists of multiple logical files (called relations). Each logical file has 
one or more keys by which the logical records may be retrieved. There are 
no entity relationships of any kind connecting the logical files. The 
entity relationships can only be determined by comparing values of attrib- 
utes of different entities. ® 


A simple list of the attributes of each logical ‘record type, with an 
indication of the keys is sufficient to describe a model. For example, 
the following describes the relational model of the accounting problem: 


Logical File Attributes 
Department Dept #, Deptname, Depthead 

Expense Exp #, Expdesc 

Account Acct #, Budamt, YTDCR, YTDDB 
Transaction CRAcct #, DBAcct #, Amt, Date, Ref 


Notice that transaction has two keys. Multiple keys are allowed ir the 
relational model. 


This model is unquestionably the simplest in appearance, and that is 
probably its greatest strength. It also has a firm mathematical founda- 
tion. Some authors? regard it as the most fundamental of the three models. 
However, it is probably the least implemented model because of two problems. 


The first is a flaw in the model - the lack of explicit entity rela- 
tionships. This can lead to what are called "insertion anomalies" and 
“deletion anomalies." For example, if a transaction is inserted, in our 
accounting problem, for which no credit account exists in the account 
logical file, the model will accept it. Likewise, a department could be 
deleted, thus "orphaning" the accounts associated with that department. 
Thus the rules necessary to avoid these anomalies must be imposed extern- 
ally to the model. 


The second problem is not so much with the model as with the implemen- 
tations. The model makes it easy to request operations which are logically 
simple, but which require considerable resources and time to execute. 

Thus relational systems have earned a reputation for inefficiency. 


Normalization 


This is one of the most important and poorly understood steps in 
designing a database. Normalization is essentially the process of dis- 
covering and isolating the entities represented by the data. There are 
three levels of normalization and the topic is discussed by most authors*~’ 
with varying degrees of clarity. Atre? presente an unusually lucid dis- 
cussion of normalization. 


Normalization is nearly always presented in mathematical terms which, 
unfortunately, discourages some from investigating it further. A complete 
discussion is beyond the scope of this paper. However, normalized data 
will have the following advantages over intuitively designed, or unnor- 
malized data: 


1. Numerous types of insertion and deletion anomalies will not occur. 
These anomalies are of the type where the insertion or deletion of one 
entity has an unexpected or undesirable effect on another entity. 


2. All entities will be readily accessible. Functions thought of after 
the database is designed will not require restructuring of the data- 
base. 


3. A higher degree of data independence is possible. Programs are less 
likely to need change as the database is changed. 


Neither the models nor the database Systems have any way to enforce 


normalization. However, failure to normalize the data will inevitably 
create serious problems. 


Mapping 


Mapping is a series of transformations on the structure of the data- 
base from its inception to the ‘final, physical, database. There are five 
states in which the data is structured: 

1. Initial data description 

2. Normalized data description 
3. The database model 

4. The schema 

5. The database 

The mapping from the initial form to the normalized form is called 
"normalization" as described earlier. Normalization actually includes 


three separate transformations. 


The mapping from the normalized form to the model is frequently accom- 
panied by some compromises. If, for example, a hierarchical model is used, 


and the data is not inherently hierarchical, an artificial constraint is 
placed on the structure. Likewise, it may be necessary to “unnorma lize" 
the data to some degree to fit the model. 


Mapping from the model to the schema is really two activities that 
are done in parallel. First, the model must be mapped to the actual 
database systems. Some systems will be very close to the model and present 
little difficulty. Others may impose either structural or efficiency con- 
straints which cause the structure to be altered significantly from that 
of the model. For example, the two-level limitation of Image requires 
compromises from the network model. 


Second, the data structure must be expressed in a form acceptable to 
the database system. The form is called a "Data Description Language” 
or DDL. All database systems have a DDL. Some have a formal syntax, such 
as Image, while others may be conversational, such as Relate/3000. The 
data structure description expressed in a DDL is called a "schema." 


The final transformation, of the schema into a database, is done by the 
database system. In most systems it is automatic with feedback in the form 
of error messages, status reports, and statistics. 


Implementation Considerations 


The following items are factors to consider in judging the merit of a 
particular database system. Until the perfect system is developed, some 
will always be better than others on specific points. Different users will 
weigh these factors differently. However, all should be considered before 


‘a selection is made. 


1. Mapping: What constraints are imposed when mapping from the model to 
the schema? Do significant changes have to be made? Are some things 
allowed, but not done because of performance considerations? 


2. Data Manipulation Language (DML): The DML is the form in which requests 
are transmitted to the database system. Is the DML powerful? Is it 
easy to understand? Is it flexible? Can it be used from an applica- 
tion program? Is there a "stand-alone" mode? 


3. Performance: 


a) Run efficiency: Are efficient search algorithms used? Is response 
time good? Are (logically) unnecessary accesses to secondary 
storage required? 


b) Storage efficiency: Is most storage space used for data? Do 
indexes, pointers, or other "non-data" items use up excessive 


space? 


4. Concurrency: Has adequate thought been given to the problem of multiple 
users updating the database? What penalties or complications arise 


from shared access? 
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5. Restructuring: What needs to be done to change the database structure? 
What resources are required? What effect does restructuring have on 
existing applications? What must be done to initially load the data- 
base? 


6. Security: How well protected is the data from unauthorized access? 
At what level or levels is security imposed: database, file, record 
or item? , 


7. Integrity: Is the database prone to develop internal inconsistencies 
(broken chains, missing records, etc.)? Do aborts or crashes cause 
problems? What provisions are there for checkpointing (back-up copies) 
and journaling (transaction logging) and recovery? 


8. Data Independence: Are application programs isolated from the physical 
storage considerations? Can changes be made in the physical or logical 
structure of the database without changing existing programs? 


These implementation considerations, together with the strengths and 
weaknesses of the model on which it is based, will be used to judge each 
of the systems considered in the next section. 


Three Implementations 


This section of the paper will consider three database s 

ystems: Image 
Relate/3000, and Rel*Stor. For each of these systems, the strengths aad 
weaknesses of the model and the implementation considerations will be dis- 
cussed. Finally vendor information will be provided. 


Image/Query 


Image! ° is based on the network model. As such it enjoys the benefits 
of explicit entity relationships of the 1:N variety, and even extends the 
concept by allowing the N entities to be ordered by the value of an attrib- 
ute of that entity. 


The DDL uses a formal, but concise, syntax. The mapping is straight- 
forward with one glaring exception: a logical file (called a "set" in 
Image) cannot both be on the "1" side of some entity relationships and on 
the "N" side of others. This limits the system, physically, to two levels. 


The problem is caused by the distinction between two kinds of files: 
masters and details. Masters are direct access files where a record is 
located by hashing on a single key. The hashing algorithms are effectively 
implemented and work with good efficiency. Detail files are essentially 
sequential-chronological files. Entity relationships are implemented using 
pointers to form a linked list or "chain" linking all related records. 

Each chain starts and ends on one record in a master set. The chain links 
any number of records (64K maximum) in a detail set. One master record 
may originate up to 16 different chains. One detail record may be linked 


N 


9 


L3 


into as many as 16 different chains. Detail records are normally accessed 
by following a chain from a master record. Sequential access is possible 
for both master and detail records. 


The two-level structure causes difficulties, and requires compromises 
when mapping from model to schema. For example, the following data struc- 
ture diagram represents the Image implementation of the accounting problem. 
Trapezoids are used to represent master sets while rectangles represent 
detail sets. Chains are represented by solid arrows while logical rela- 
tionships (implemented programatically) are shown by broken arrows. 


Department Expense 














Exp #, 


Expensedesc. 


Dept # 





» Deptname 










Depthead 








Dept. #, Exp i, 
Budgetamt, YTD CR ant, 
YTD DB amt 






| Acct # 


Account Indx 


CR Acct # CB Acct # 


Transaction 


Figure 3 


The broken underlines indicate that the underlined data item is a key 
only via the associated master. Image, however, requires that such fields 
be physically present in spite of the logical redundancy. 


The ACCOUNT and ACCOUNTINDX sets are logically the same, but two are 
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required to circumvent the two-level problem. This requires redundant 
Storage and additional access to secondary storage. 


The schema for this data base is as follows: 


BEGIN DATA BASE ACCTDB; 
PASSWORDS: <<NONE>> 


ITEMS: 
DEPT, X4; <<DEPT #>> 
EXP, X4; <<EXP #>> 
DEP TNAME, X20; <<DEPARTMENT NAME>> 
DEPTHEAD, X20; <<DEPT HEAD'S NAME>> 
EXPDESC, X20; <<EXPENSE DESCRIPTION>> 
BUDAMT, I2; <<BUDGET AMOUNT>> 
YTDCR, I2; <<YEAR-TO-DATE CREDIT TOTAL>> 
YTDDB, I2; <<YEAR-TO-DATE DEBIT TOTAL>> 
ACCT, X8; <<ACCT # = DEPT#EXP#>> 
ACCTCR, X8; <<CREDIT ACCT #>> 
ACCTDB, X8; <<DEBIT ACCT #>> 
AMT, I2; <<TRANSACTION AMOUNT>> 
DATE, I2; <<TRANSACTION DATE>> 
REF, X6; <<ACCOUNTING REFERENCE>> 
SETS: 


NAME: DEPARTMENT, MASTER; 
ENTRY: DEPT(1), 
DEPTNAME, 
DEPTHEAD; 
CAPACITY: 23; 


NAME: EXPENSE, MASTER; 
ENTRY: EXP(1), 
EXPDESC; 
CAPACITY: 23; 


NAME: ACCOUNT, DETAIL; 
ENTRY: DEPT (DEPARTMENT) , 
EXP (EXPENSE), 
BUDAMT, 
YTDCR, 
YTDDB; 
CAPACITY: 100; 


NAME: ACCOUNTINDX, MASTER; <<LOGICALLY PART OF "ACCOUNT ' >> 
ENTRY: ACCT (2); 
CAPACITY: 101; 


NAME: TRANSACTION, DETAIL; 
ENTRY: ACCTCR (ACCOUNTINDX), <<CREDIT ACCT #>> 
ACCTDB (ACCOUNTINDX), <<DEBIT ACCT #>> 
AMT, 
DATE, 
REF; 
CAPACITY: 6000; 


END. 
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A variety of data types may be defined in the DDI. These are: ee 
16 bit signed integer 
32 bit signed integer 
64 bit signed integer 
16 bit unsigned integer 
32 bit floating point DBLOCK 
64 bit floating point 

Character string 

Zoned decimal 


DBOPEN 


Packed decimal DBFIND 
No provision is made to add user defined data types. DBGET 
Image's DML consists of procedure calls which are compatible with all DBBEGIN 


the standard languages. A summary of the procedures and their functions 
appears in Figure 4. An application program called "Query" is supplied 


with Image. !! This program can be used interactively to access a database. DBMEMO 
It also serves as a report generator. Its usefulness is limited by its nepur 
inability to look at more than one file at a time. However, it works very 
well otherwise and is simple enough to be used by non-programmers. Manip- DBUPDATE 
ulations such as sorts and totals may be specified. 
DBDELETE 
The run efficiency of Image is generally good. Performance problems 
are usually the result of design errors. For example, adding a detail DBEND 
record to a long ordered chain requires a sequential search of the chain. 
If there are 1000 detail records on the chain, 500 of them will (on the DBUNLOCK 
average) have to be read to determine the logical placement of the new 
record. Normally this would require 5090 disk accesses! Thus, long ordered: 
chains should be avoided. DBCLOSE 
Another source of performance problems can be record-level locking. Hare 


Image uses dynamic locking to handle the concurrency. The locking may be 

done at the database level, file level, or record level. The lower the 

level, the greater the complexity!” and the greater the overhead involved. DBEXPLAIN 
The overhead at the database level is negligible; at the record level it 

is considerable. 


Much of the time, blocking of records does not help reduce disk accesses. DBERROR 
There is a provision to store detail records, that share a chain, in the 
order in which they occur on the chain.. This physical ordering can only be 
done as part of restructuring and is not dynamically maintained. Thus 
there is usually a requirement for one physical access for each logical DBCONTROL 


access. 


Insertions and deletions require considerably more than one access. 
To insert a detail requires a minimum of four accesses for each chain in- 
volved as well as the write to put the record out. A deletion will usually 
require six accesses per chain. 


The designer can consider these factors in mapping the schema and the 
resulting Image implementations can be as efficient as corresponding 
non-database applications. 


Eee L311 


FUNCTION 


Initiates access to a data base. Sets up user's access 
mode and user class number for the duration of the process. 


Locks one or more data entries, a data set, or an entire 
data base (or a combination of these) temporarily to 
allow the process calling the procedure to have exclu- 
sive access to the locked entities. 


Locates the first and last entries of a data chain in 
preparation for access to entries in the chain. 


Reads the data items of a specified entry. 


When logging, designates the beginning of a transaction 
and optionally writes user information to the logfile. 


When logging, writes user information to the logfile. 
Add new entries to a data set. 


Updates or modifies the values of data items that are 
not search or sort items. 


Deletes existing entries from a data set. 


When logging, designates the end of a transaction and 
optionally writes user information to the logfile. 


Releases those locks obtained with previous calls to 
DBLOCK. 


Terminates access to a data base or a data set, or resets 
the pointers of a data set to their original state. 


Provides information about the data base being accessed, 
such as the name and description of a data item. 


Examines status information returned by an IMAGE pro- 
cedure that has been called and prints a multi-line 
message on the SSTDLIST device. 


Supplies an English language message that interprets the 
status information set by any callable JMAGE procedure. 
The message is returned to the calling program in a 
buffer. 


Allows program operating in exclusive mode to enable or 
disable the "deferred update" option. 


Figure 4 
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The storage efficiency of Image is generally good, but again there 
are exceptions. Each chain requires 10 bytes for chain information in 
each master record, and 8 bytes in each detail record. Where several 
chains are involved this can become significant. Where the amount of 
data per record is small and the number of chains is high, the total stor- 
age required can be several times that required by the data. However, 
this is not typical. A modest "root file” is required to contain the 
schema and statistical information, but this is negligible in size. 


As noted above, concurrency is handled by dynamic locking at several 
different levels. As with any dynamic locking situation, care must be 
exercised to avoid lockouts or deadlocks. Experience has shown that a 
dozen or so interactive users can share access to a database locking at 
the database level without serious contention problems. More can probably 
be accommodated with lower levels of locking. 


Restructuring of an Image database is awkward at best and nearly in- 
possible at worst. Essentially, fields may be added to records, and 
existing fields may be redefined. The maximum capacity of files may be 
changed, and chains may be added or deleted. Sometimes, but not always, 
new files may be added. 


Restructuring is done with the utilities DBUNLOAD and DBLOAD. DBUN- 
LOAD dumps records from the old database to magnetic tape. The old data- 
base is then purged and the new one is created from the revised schema. 
DBLOAD then loads the data from the tape to the new database. All poin- 
ters and chains are built anew by DBLOAD and the process can be very slow. 
The new database must be very similar to the old as no structure infor- 
mation is carried on the tape. 


Security is very good with Image. In addition to the MPE file security, 
Image has an internal security mechanism that is very flexible. Up to 
63 user classes, with associated passwords, may be defined. For each file 
and/or field, it is possible to specify which classes are allowed read 
access and which are allowed read/write access. All other user classes 
have no access. Image files are "privileged files" and cannot be accessed 
except through Image or by a privileged mode user. 


The integrity of Image is unusually high. Crashes seem to cause a 
problem only when caused by a catastrophic hardware failure. Even then 
the problem can usually be fixed by deleting and replacing the record(s) 
involved. At worst a DBUNLOAD/DBLOAD will repair all structural damage. 


Checkpointing can be done easily by using the utilities DBSTORE/ 
DBRESTOR. These dump the files, with pointers, to tape and from tape to 
disk. Since no restructuring is done, they are very fast and efficient. 


Journaling may be done with the transaction logging feature of Image. 
A utility is available to process the logged transactions to a check- 
pointed version of the database to recover all processing. 


The degree of data independence can vary widely depending on the 


application programs themselves. At the low end of the spectrum, a pro- 
gram can, on a DBGET, request a physical record. At the other end, it can 
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request the specific fields wanted and the order in which they are deliv- 
ered. A useful option is that of asking for the same list of variables 
used on the previous access of that file. This permits a logical “view" 
to be defined by the initial access(es). Thereafter the program sees this 
same view. 


Image is structured as a set of user-callable procedures and several 
utilities plus Query. The utilities are only needed to restructure or 
recover the database and are not used for routine functions. All proced- 
ures are part of the application program's process. However, an extra 
data segment is created for each database that each process has open. In 
addition, all processes using a database share an extra data segment that 
serves as a common buffer and locking mechanism. 


Image is a well established product and is nearly error free. It is 
available from: 


Hewlett-Packard Co. 
19447 Pruneridge Avenue 
Cupertino, CA 95014 


Relate/3000 


Relate is based on the relational model. Thus it enjoys the benefits 
of simplicity at the expense of losing the explicit entity relationships 
found in the other models. It is an unusually faithful implementation. 
with all standard features. 


The DDL is conversational and informal. No "database" per se is defined. 
However, files (called relations in this model) are defined along with the 
name, and internal and external description of each field. These descrip- 
tions are stored in the “user label" area of each file. Thus the files 
are independent of one another. A database consists of those files a user 
has open at any given time. 


Most relational systems provide for two types of relations or logical 
files. A “primary relation" is a permanent part of the database and is 
usually implemented as a physical file. A “derived relation™ is one 
created during the run of an application and is usually not permanent. 
These derived relations are of two kinds: a "snapshot" is usually created 
by copying data from a primary relation to a new file. Thereafter it is 
independent of the original data. An "evolving view" is a rule that says 
how the derived relation is formed from the primary relations. The data 
remains in the primary relation. 


Relate allows snapshots to be created at any time. In addition, evolv- 
ing views may be created in two ways. A temporary, core resident view may 
be specified with the SELECT command. A permanent evolving view may be 
specified by the CREATE VIEW command. These are stored in separate, short 
files which contain the definition of the view, but no data. 
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A file (or relation) is created by the CREATE FILE command while keys 
are specified by the CREATE INDEX command. Examples of these commands are 
perhaps the most concise way to describe the DDL. The accounting problem 
will be used in these examples. Note that file names are limited to seven 
characters. Comments are enclosed in brackets { } but are not part of the 
session dialog; computer output is underlined: 


{Create the department file} 

> CREATE FILE DEPART; RECORDS=23 

ENTER FIELD NAME, TYPE, LENGTH{.DECIMALS } 

? DEPT, ALPHA, 4 

2? DEPTNAME, ALPHA, 29 

? DEPTHEAD, ALPHA, 2@ 

2 // 

THE "DEPART" FILE HAS BEEN CREATED AS A PERMANENT RELATE/3G@@ FILE. 
{Create the expense file. Here the description for each field is contained 
in the CREATE command} 

> CREATE FILE EXPENSE ; RECORDS=23 ; FIELDS=(EXP , ALPHA, 4) (EXPDESC, ALPHA, 2G) 

THE "EXPENSE" FILE HAS BEEN CREATED AS A PERMANENT RELATE/3@Q@ FILE. 


{A command may extend over multiple lines as follows} 

> CREATE FILE ACCOUNT; RECORDS=19@; FIELDS=& 

&> (DEPT,ALPHA, 4) ,& 

&> (EXP,ALPHA, 4) ,& 

&> (BUDAMT, DOUBLE, 13;COMMA=YES) ,& 

&> (YTDCR, DOUBLE, 13;COMMA=YES) ,& 

&> (YTDDB, DOUBLE, 13;COMMA=YES) 

THE "ACCOUNT" FILE HAS BEEN CREATED AS A PERMANENT RELATE/3QQ9 FILE. 


{Finally the transaction file is created} 

> CREATE FILE TRANS;RECORDS=6@G¢ 

ENTER FIELD NAME, TYPE, LENGTH{.DECIMALS} 

aS DEPTCR, ALPHA, 4 

? EXPCR,ALPHA, 4 

? DEPTDB,ALPHA,4 

? EXPDB,ALPHA, 4 

AMT , DOUBLE, 13, COMMA=YES 

DATE, REAL, 8; FORMAT=""MM/DD/YY" 

REF , ALPHA, 6 

Lf ; 
THE "TRANS" FILE HAS BEEN CREATED AS A PERMANENT RELATE/3@@@ FILE. 
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{Next the keys are defined with the CREATE INDEX command. The SET PATH 
command defines the "current" file for indexing} 

> SET PATH DEPART 

> CREATE INDEX BY DEPT;UNARY 

{The "unary" specifies that keys must be unique} 

> SET PATH EXP 

> CREATE INDEX BY EXP;UNARY 

{The following index contains one key formed by concatenating two fields} 

> SET PATH ACCOUNT 

> CREATE INDEX BY DEPT, EXP;UNARY 
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{The following indexes each have two keys, each of which is the concaten- 
ation of two items; neither key must be unique} 

SET PATH TRANS 

CREATE INDEX BY DEPTCR,EXPCR 

CREATE INDEX BY DEPTDB,EXPDB 
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Each data file has one index file associated with it. Up to nine 
indexes may be defined for each data file. All indexes for one data file 
are stored in the one index file. The indexes are structured as "B-trees,."!% 
The B-tree is a tree structure which neatly solves the problems of making 
additions and deletions to the index, and is very efficient for retrieval. 
Appendix B of the KSAM manual?® has a good presentation on B-tree indexes. 


Eight different data types may be specified for the fields. These are: 


Character String 

16 bit unsigned integer 
16 bit signed integer 
32 bit signed integer 
32 bit floating point 
64 bit floating point 
Packed decimal 

Zoned decimal 


There is currently no provision for user defined data types, but this 
feature is under consideration. 


An external format is also specified which has several options and 
some nice features. It is not as flexible as the PICTURE clause of COBOL 
or the FORMAT statement of FORTRAN, but better than the facilities found 
in Query. 


The DML consists of two parts: commands and procedure calls. By far 
the greatest power and flexibility is in the commands. The procedures 
provide a better interface for application programs, in some cases, and 
somewhat more flexibility. Both commands and procedures may be accessed 
from an application program. The commands can also be used with Relate 
running as an interactive program as in the examples above. 


The diagram in Figure 5 illustrates the program structure of Relate. 
The program Relate is the workhorse of the system. It is all that is 
needed when Relate is run as an independent program. When Relate is used 
from an application program, the "host language interface" library pro- 
cedures are called by the program. These procedures, in turn, create a 
son process which runs the Relate program. All calls to these procedures 
are passed to the son process (Relate) for execution. 
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Figure 5 


The following table lists the Relate commands with a brief description 
of the function of each. These commands may be used in the stand-alone 
mode or from an application program. 


Command 


ADD 


ALLOW 


CHANGE* 


CLOSE 


COMPARE 


CONSOLIDATE* 


CoPY* 


CREATE FILE 


CREATE INDEX 


CREATE VIEW 


DELETE* 


DISABLE SECURITY 


Function 
Adds a record to the current file. 
Sets the capabilities of different users. 
Modifies record(s) ina file. 
Closes files or databases. 


Compares contents of two files and selects either 
matching or unmatched records. 


Creates a subset of the current file. 
Copies the current file to another. 
Creates a Relate/3QQ@ file. 

Creates an index for the current file. 


Creates an "evolving view'' and stores its descrip- 
tion in a file. 


Purges selected records from current file. 


Releases Relate security. 
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Command 
DISALLOW 
ENABLE SECURITY 
END 
EXIT 
EXECUTE 
HELP 
LABEL* 

LET* 
MODIFY 
NOTE 
Database 
OPEN {Path 
File 
PRINT* 
PURGE INDEX 
PURGE VIEW 


RECOVER* 


REDO 


REORGANIZE 


SELECT* 


SET INDEX 


SET PATH 


SHOW 


SORT* 


SUM* 


Function 
Inverse function of ALLOW. 
Turns on Relate security. 
Terminates Relate program. 
Terminates Relate program. 
Causes Relate commands in a file to be executed. 
Displays information about commands. 
Prints records in label format. 
Makes arithmetic or alphabetic assignments. 


Changes the field formats or descriptions for the 
current file. 


The note command begins a comment line. 


Opens the named database (Image) or file. "Path" is 
an alternate name for a file. 


Displays selected data from current file on $STDLIST. 
Purges an index from the current file. 
Purges the named view. 


Restores records that have been logically, but not 
physically deleted. 


One line edit function for previous command. 


Physically removes logically deleted records and, 
optionally, changes file capacity. 


Creates an “evolving view" and holds it in main memory 
for use by subsequent command(s). 


Specifies which index is to be used. 
Specifies which file is to be used. 
Displays information about open files and indexes. 


Copies selected records from the current file to 
another file in order specified by sort key(s). 


Totals one or more fields in selected records. 
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Command Function 
SYSTEM Sets global parameters. 
TERMINAL Specifies terminal characteristics. 
UPDATE Merges selected files. 


Those commands marked with an asterisk in the table above allow subsets 
of the records in the current file to be selected in either or both of two 
different ways. The first is by a range or ranges of values of fields that 
are indexed. For example: 


> SET FILE PEOPLE 
SET INDEX NAME 
tat "G6" PRINT 


Ivivi 


will print the records for all people whose names are in the range A-G. 
The selection may be further qualified by a ''FOR" clause. For example: 


> "A"/"G" PRINT FOR DEPT = "SALES" AND SALARY > 25969 
will print the records for all people whose names are in the range A-G, who 
work in the sales department, and whose salary is greater than 25999. Both 
ranges and FOR conditions may be compounded. 


Again referring to the accounting problem the following dialog illus- 
trates the power of some commands. As before, comments are in brackets, 
computer output is underlined. 


{Open department file and add entries to it} 

> OPEN FILE DEPART 

> ADD 

ENTER DEPT, DEPTNAME, DEPTHEAD 

DEPT? {Here the one field, or all three fields, may be entered. If 
fields have been specified in a hierarchical form, only fields 
that differ from record-to-record need be entered. } 

DEPT? // {Returns control to command interpreter. } 


{Next, a SELECT command is used to define an evolving view that combines 
data from two different files. The COPY command then copies this view to 
another file.} 

> SELECT DEPART.DEPT, EXPENSE. EXP 

{This will select the dept # from the department file and the exp # from 
the expense file. There are 8 records in the department file and 9 in 
the expense file. A total of 8x9=72 combinations are pussible, and that 
many records will be copied by the next command. } 

> COPY TO ACCOUNT 

{We now have 72 accounts in the ACCOUNT file. We would next like to 
create one transaction for each combination of credit acct # and debit 
acct # except that the same account number may not appe.r in both places. 
This will give 72x72-72=5112 transactions. There may be more elegant 
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ways to do this, but the following sequence worked. It was necessary to 
create a temporary file similar to ACCOUNT but with different field names. } 


> CREATE FILE TEMP; STRUCTURE=ACCOUNT 

{This creates a file of the same size and with the same field definitions 
as ACCOUNT. } 

> SET PATH ACCOUNT 

> COPY TO TEMP 

{TEMP now contains the same data as ACCOUNT, } 

> SET PATH TEMP 

> MODIFY DEPT; NAME=DEPTDB 

> MODIFY EXP; NAME=EXPDB 

{The field names in TEMP have been renamed. } 

> SET PATH ACCOUNT 

> MODIFY DEPT; NAME=DEPTCR 

> MODIFY EXP; NAME=EXPCR 

{The field names in ACCOUNT have been temporarily renamed. Names of fields 
in ACCOUNT and TEMP now correspond to those in TRANS. Next, an evolving 
view will be defined as the product of account numbers in these two files, 
excluding cases where the two account numbers are identical. These 5112 
transactions will then be created with the copy command. } 

> SELECT ACCOUNT .DEPTCR, ACCOUNT. EXPCR, TEMP .DEPTDB,TEMP.EXPDB WHERE& 

&> ACCOUNT.DEPTCR <> TEMP.DEPTDB OR ACCOUNT.EXPCR <> TEMP.EXPDB 

> COPY TO TRANS 


Space does not permit a more complete display of the use of the con- 
mands. A rather nice demonstration package is available from CRI that 
shows more of the commands. A few hours "playing" with the system is also 
very instructive. 


The programmatic interface consists of the eleven procedure calls listed 
in Figure 6. Notice that any of the commands may be used through the RELATE 
procedure. A "cursor" is a file control block. Multiple cursors may be 
used allowing multiple files to be processed concurrently, 


The big problem with relational systems has always been run efficiency. 
Part of the problem comes from the apparent simplicity of the model - it 
is very easy to give a logically simple command that requires enormous 
resources. One of the authors, while experimenting with Relate, inadver- 
tently gave a command that required 72° = 373,248 logical file accesses. 
It required about 40 minutes to execute and, but for good blocking effic- 
iency could have required much longer. A better way was found to do the 
same function in a few seconds. 


The other source of low efficiency has been the indexing system. The 
B-tree structure has solved this nicely and this particular implementation 
is nearly optimally efficient. For example, a new index was created for 
the TRANS file of 5112 records in 78.5 seconds of CPU time. This works 
out to 15.4 milliseconds per record which is excellent. 


Blocking factors are automatically chosen, and again, seem to be nearly 


optimal. Disk accesses appear to be the minimum possible in most cases 
tested. 
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Procedure Function 

RELATE Passes a command to the RELATE/3@@@ data base management 
system. 

RDBADD Adds a new record to the file associated with the passed 
cursor. 

RDBBIND Binds a memory location for a return value or a substi- 


tution variable. 
RDBCLOSE Closes a cursor. 


RDBDELETE Deletes the current record from the file associated with 
the passed cursor. 


RDBERROR Returns information on an error condition that exists in 
a cursor. 

RDBINFO Returns information on the current file or status of the 
systen. 

RDBINIT Initializes a cursor. 

RDBPOINT Positions a pointer to a specific record for reading. 


This call does not function on views or selections. 
RDBREAD Reads the next record from the associated cursor. 


RDBUPDATE Updates the current record on the file associated with 
the passed cursor. 


Figure 6 


In short, both storage and run efficiencies seem to be very close to 
the ideal. Where performance problems arise, they can likely be traced 
to the ease with which some very awkward operations can be requested. 


Concurrency is handled by dynamic locking of files. It may be enhanced 
beyond the file level in subsequent releases. Even at the file level, 
experience with Image indicates that it should be effective. 


Restructuring is certainly one of the strong points. of Relate. New 
files are easily defined and data from one or more files can readily be 
copied to the new file, with undefined fields zeroed or blanked. More- 
over, Relate may be used with Image, KSAM, or MPE files as well as Relate 
files. Many of the commands including OPEN, COPY, PRINT, and CLOSE will 
work with these other file types. Not only does this give the user the 
option of combining these other file types into a Relate database, but it 
also makes the task of converting from the other file types to Relate files 
a trivial exercise. After one has struggled with restructuring Image, 
Relate seems almost too good to be true! 
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Security is defined with the ALLOW command. Essentlally this speci- 
fies which users or groups of users can execute various groups of commands. 
For example use of the CREATE and PURGE commands can be restricted to one 
user. However, these security features only are effective for users going 
through the Relate system. Only the MPE file security is effective for a 
user who goes into a Relate file through the MPE file system. 


An option exists to considerably strengthen the security by making the 
Relate files privileged files as Image does. However, this presently in- 
volves giving PM capability to the account and to the database administrator. 
Other options are under study to improve the security including encryption. 


The integrity is similar to Image except that journaling (logging to 
a tape) and recovery from the log tape are not presently implemented. 
They could be done through application programming. 


Data independence is also similar to Image. The user may accept all 
fields in the record as they physically occur or specify the fields and 
their order. 


Relate/3$Q9@ is a new product and, as with any new product of this com- 
plexity, can be expected to have some bugs in it. However, it appears to 
be soundly conceived, efficiently implemented, and a very effective tool. 
It is available for a one-time fee of $18,500 which includes the first 
year's maintenance. Maintenance after the first year will be 15% of the 
(then) current selling price. Relate is available from: 


Computer Resources, Inc. 
2750 El Camino Real 
Mountain View, CA 94040 
(415) 941-4646 


Rel*Stor 


Rel*Stor is also based on the relational model and, with Relate, 
shares the particular strengths and weaknesses of that model. Unlike 
Image and Relate, which were created specifically for the HP/39@9, Rel*Stor 
is implemented on other systems. 


The DDL for Rel*Stor is slightly more formal than that for Relate, but 
closer to Relate's than Image's. The DEFINE command is used to create a 
file (relation or "table" as it is called in the Rel*Stor manual'®). A 
database is created using the DEFINEDB command. This command specifies 
the name of the database and gives upper limits for the number of data 
files and users. Three directories are then created to store information 
on the database and its users, but no data files are specified or created. 


Derived relations can be created as snapshots through the RETRIEVE 


command. The RANGE command allows the data for the snapshot to be gathered 
from more than one file. There is no provision for “evolving views." 
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The DEFINE command is functionally and syntactically similar to the 
CREATE command of Relate. For example, the ACCOUNT file would be created 
by the following: 


DEFINE ACCOUNT 
DEPT STRING 4, 
EXP STRING 4, 
BUDAMT INTEGER 1@, 
YTDCR INTEGER 19, 
YTDDB INTEGER 1G, 
PRIME=2 
SIZE=23; 


The PRIME=2 clause indicates that the first two fields (concatenated) 
constitute a unique key for each record. There is no provision for files, 
such as the transaction file, where no combination of fields yields a 
unique key. (Two transactions could be identical in all respects.) Like- 
wise there is no provision for multiple keys. The single key may include 
several fields (in order of declaration starting with the first). The 
indexes are structured as B-trees with the advantages of ease of change 
and efficient retrieval. 


There are only three data types specified, and data is stored in ex- 
ternal (ASCIL) form rather than internal (Binary) form. Data type appears 
to matter only when arithmetic operations are performed. The three types 
and the upper and lower limits on their "width" are: 


Integer 4 to 12 bytes 
Real 8 to 12 bytes 
String -—- 


These widths would allow both 16 and 32 bit integers, but only 32 bit 
floating point. No formatting capability is included. 


The DML is quite rich and nearly as complex as a programming language such 
as Basic. This richness could be seen as Rel*Stor's strongest point. Its 
complexity could be a weak point. 


Before proceeding to the DML it is necessary to understand the program- 
matic components of Rel*Stor and how they function. A program called the 
Relational Data Handler or RDH is the main workhorse of the system. The 
RDH is run as a son process of the user's process. The user's process 
may either be an application program or a program called the Terminal 
Interface Process or TIP. See Figure 7. 


TIP serves as a conversational interface, tex: editor, and other mis- 
cellaneous functions. It operates in three different modes: control mode, 
edit mode, and administrative mode. The control mode a:lows the user to 
formulate queries, send them to the RDH, and see the results. The edit 
mode allows the user to compose, edit, modify and sav> qu2ries. The admin- 
istrative mode allows qualified users to define new databases, grant users 
access to databases and retrieve data base statistics. There are 45 TIP 
commands altogether as shown in Figure 8. 
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Figure 7 
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Name 
APPEND 
BYE 
COMPTi.E 
CONTINUE 
Dba 
EDit 
END 

GO 
HELLO 
LISVREL 
| PRaili 


rhini LO 


bist Wi RK 
Bow 


SaVERR 


SEND 


SETPAGE 


SETRR 
SETWSR 


SHOWNE 
STATISTICS 


SYSTEM 


TIP Control Commands 
Meaning 

append, insert, or change data in a relation 
terminate a session with a aatabase 
translates Buffer to code and checks syntax 
continue query to retrieve next page of data 
switch from Control to DBA mode 
switch from Control to Edit mode 
return control to the operating system 
COMPILE and RUN the Textual Buffer 
initiate a session with a database 
list rela:ions and their data attributes 
change automatic PRINTRR mode 


print tne number of disk accesses in your last 
request 


print the Result Relation 
send the COMPILED Buffer 


save the Result Relation, formatted for a LOAD 
command 


send a canned query for processing 


set the maximum rows per page in the Result 
Relation 


reset the size of Result Relation file 
reset the size of workspace relation file 


shows the filenames and parameters of present 
session 


print the statistics associated with your last 
query 


print the system configuration parameters 


Figure 8 (contd) 
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Name 
TIME 


// 


ADD 
DELETE 
END 
JOIN 
KEEP 
LIST 
PURGE 
REPLACE 
TEXT 


// 


ABORT 
ALTUSER 
COOL 
DEFINEDB 
DEFINEI 
END 


LISTDBS 


TIP Control Commands 
Meaning 
print the time required to complete last query 
terminates APPEND command 


terminates APPEND command 


TIP Edit Commands 
add lines to the Buffer 
delete lines from the Buffer 
return to control mode 
JOIN together the Buffer and a KEEPed file 
save the vontenta of the Buffer in a permanent file 
list Lines of the Buffer 
dedete a tile created by the KEEP command 
replace Lines of text in the Bulfer 
bring @ permanent file into the Buffer 


terminate ADD or REPLACE command 


TIP Administrator Commands 
set query control point to inactive 
change or add to the capability of a user 
to be implemented 
define a new data base 
initial installation of RELATE 
return to control mode 


list data base statistics or all data base names 


Figure 8 (contd) 
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Name 
LISTUSER 
NEWUSER 
PURGEUSER 
REMOVEDB 
RESTRICT 


WARM 


TIP Administrator Commands 

Meaning 
list directory for one user or all users 
enter a new user with RETRIEVE capability 
remove a user from a data base directory 
remove a data base 
to be implemented 


to be implemented 


Figure 8 
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The programmatic interface to the RDH consists of four library pro- 
cedures: 


Procedure Function 

STARTRDH Creates the RDH process 

TXTBFMGR Sends a query to RDH 

PROJECT Returns one field at a time from the result of 
the query 

GETDESC Returns a description of the result of a query 


Queries are processed in a "batch" mode by the RDH; i.e. a query is 
passed to the RDH, the result of the search is placed in a temporary file 
called the "result relation." The results may then be interrogated or 
even saved as a new, permanent file. 


Thus, in spite of the numerous TIP commands, it is the RDH commands 
that constitute the true DML, and even include most of the DDL. Figure 9 
lists the RDH commands and operators which may be combined in the usual 
ways. - 


The RETRIEVE command is the primary read verb and the WHERE clause the 
qualifier. For example, the following query would retrieve all transac- 
tions debited to department #42 for expense categories 10-29 if the amount 
exceeds $100.00. 


RANGE X = ACCOUNT ; 
RETRIEVE X.DEPTDB, X.EXPDB, X.DEPTCR, X.EXPCR, AMT, DATE, REF 
WHERE 

X.DEPTDB = 42 AND X.EXPDB >=1@ AND X.EXPDB < 3¢ 

AND AMT > 19¢9.@¢ 


The LOAD command may be used to load data to a Rel*Stor file from an 
MPE file. It also may be used to add new records to a Rel*Stor file. 
There is no update verb in the RDH commands. The APPEND command in the 
TIP control mode will update. The only other option is to copy the entire 
file, modifying the necessary records. This seems to reflect a strong 
"batch" orientation rather than an on-line orientation. 


Little can be said about performance since the product was not avail- 
able for testing. The batch orientation of the DML, however, makes it 
likely that interactive processing, for any but a read only mode, would 
be awkward at best and could be very inefficient. 


Storage efficiency is likewise less than optimum due to the storage of 
external rather than internal forms of the data. 


Concurrency is not implemented at the present time. There are plans 


to add it in 1982. At present only one user at a time may access a data- 
base. 
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Name 
AND 

AVG 

BUT 
COLLECT 
COUNT 
DEFINE 
DELETE 
DELETEQ 
LOAD 
MAX 

MIN 

NOT 

OR 
RANGE 
REMOVE 
RENAME 
RETRIEVE 
SAVE 


SUM 


RDH Commands and Operators 
Meaning 

logical (Boolean) operator 

COLLECT function - averages real or integer 
logical (boolean) operator - same as AND 
perform function (COUNT, SUM, MIN, MAX, AVG) 
COLLECT function - counts rows 
create a new data base table 
delete rows from a data base table 
DELETE but save DELETEd rows in Result Relation 
bulk load data into a table 
COLLECT function - finds maximum in column 
COLLECT function - finds minimum in column 
logical (Boolean) operator 

logical (Boolean) operator 
specify table and assign relation variable(s) 
purge a data base table 

rename a data base table 

get information from a data base 

save the Result Relation as a data base table 
COLLECT function - adds real or integer column 
introduce qualification clause to query 
arithmetic operators - plus, minus, times, divided by 
parenthesis - determine order of operation 
value of expression is aseigned to variable 


relational operators 


relational operator - is not equal to 
relational operator - is included in - string only 


Figure 9 
-30- 


L3 29 


Security is defined by the NEWUSER and ALTUSER commands. These allow 
the administrator to control the users having access to each database, 
and the commands that each user may use. However, these security pro- 
visions are only effective for users going through the Rel*Stor system. 
Only the MPE file security is effective for a user who goes into.a Rel*Stor 
file through the MPE file system. 


Integrity is similar to Image except that there is no provision for 
journaling (logging transactions to tape) and recovery from the log tape. 
This could be implemented by application programs, however. 


Data independence is also similar to Image. The user may accept all 
fields in the record as they occur, or specify the fields and their order. 


Rel*Stor is a new product, with some features not scheduled for imple- 
mentation until next year. As with any new product of some complexity, 
it can be expected to have some bugs. It was designed to work on a variety 
of computer systems and this may well cause some compromises in its design - 
for example the "batch" orientation of the RDH. 

Rel*Stor is available for a one time fee of $20,000 which includes 
delivery, installation, three copies of the documentation, maintenance/ 
update service, and hot-line consultation for 12 months. Maintenance/up- 
date service, and hot-line consultation costs $3000 per year after the 
first year. Rel*Stor is available from: 


GTE Products Corporation 
P.O. Box 188 

Mountain View, CA 94042 
(415) 966-2371 


SUMMARY 


Any time that complex syetems are compared, it is difficult to be 
totally objective because the designers of the systems had different goals 
and viewed various features with differing importance. Likewise, users 
of these systems will have varying needs. Thus it is not possible to 
rank these systems - any one of them might be the best choice for some 
applications. The grading chart, shown following, is an attempt to objec- 
tively assess salient features of each system. Even here, however, each 
individual grade must be a subjective judgment made after considering a 
variety of dissimilar factors. 
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Grading 


In the table below, the features of each of the three systems have 
been graded in ten categories. These grades are solely the judgment of 
the authors. The grade meanings are as follows: 


A - excellent, outstanding 

B - above average 

C - average 

D - below average but useable 

F - essentially useless or non-existent 

X - unable to determine 

Image Relate/3000 Rel*Stor 
1. Mapping to system D B B 
2. DDL and data types B B C 
3. DML C A D 
4. Run performance B B X 
5. Storage efficiency C A D 
4g 

6. Concurrency B C F 
7. Restructuring D A B 
8. Security B D D 
9. Integrity A B B 
10. Data independence Cc C Cc 


Future Developments 


This paper is the result of one small step in a project to bring to- 
gether a cohesive and effective set of program development tools. The key- 
stone of this project is a data dictionary which would be shared by all 
components. At present each system (Image, Relate/3000, Rel*Stor, V/3000, 
etc.) has its own data dictionary (or fragment thereof) contained within it. 


The time has come for a centralized data dictionary. The dictionary 
would necessarily be complex enough to require a database to store it. 
Systems could share the information and the data conversion procedures 
instead of each having its own (different) version. The authors plan to 
do future work in this direction. 
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THE HP 2680A LASER PRINTING SYSTEM 


The HP2680A Laser Printing System consists of a medium-speed laser 

printer which together with its associated software, allows the devel- 

opment and printing of forms containing data, special character sets, 

company logos as well as the usual design elements making up a standard 
orm. 


The outstanding feature of this printing system is the interactive 
software which is used for development of all kinds of different 

forms, character sets, company logos and other artwork using no more 
than a standard graphics terminal and a digitiser linked up with an 

HP 3000 computer. This software has been specially designed for the use 
of the non-programmer - all instructions are entered through menus or 
special function keys on the terminal and there are various useful de- 
fault values present in the menus. In addition, sensible warning and 
error messages are displayed to prevent the user from wasting his time 
with correcting mistakes. 


Although the software is very easy to use, it has many built-in 
features allowing the user to make full use of the printing flexibility 
of the HP 2680A Laser Printer. It is the purpose of this presentation 
to describe some of these features using practical examples. 


OVERVIEW 


The structure of the software associated with the HP2680A Laser Printer 
could be represented in the form of the following equations:- 


Printout = Data File + Environment File 

Environment File = Forms + Character Sets + Page Layout 

Forms = Lines + Boxes + Shading + Headings + Logos + Signatures 
Character Sets = Characters + Logos + Signatures + Other Artwork 


The following software is available for use with the HP2680A Laser 
Printer:- 


1 - IFS2680 (Interactive Formatting System) is used for creating 
environment files. 
2-IL /3000 (Interactive Design Software) which includes two 
programmes: 
a) IDSFORM for creating forms 
b) IDSCHAR which is used for creating character set and 
logo files. 
3 ~ parious intrinsics within MPE which are used to conrol the Laser 
rinter. 
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PRINTING 


In order to control the printing out of data by means of the environ- 
ment file, a modified version of the file equation can be used 

which allows the environment file to be specified. This file 

equation also specifies the target device ie. the HP2680A printer. 


eg. :FILE PRINTOUT; DEVsEPOC;ENV=TESTENV;CCTL 
("EPOC" is the device class name for the HP2680A) 


Data which is sent to this device file "PRINTOUT" will be automatically 
merged with the environment file "TESTENV". It is sent in this form to 
ae spooler and then printed out using the specified character sets, 

orms etc. 


INTERACTIVE DESIGN CONTROL 


Since IDS/3000 has been designed with the non-programmer in mind, 
no special programming language has to be learnt in order to make 
full use of the features of this system. 


All instructions to the system are entered by the user by means of 
menus and function keys. In order to save on development time, 
useful default values are provided by the software. These are par- 
ticularly valuable when only relatively simple environments, forms 
and characters are to be designed. Warning and error messages pre- 
vent even an inexperienced user from making serious errors such as 
erasing the product of an afternoon’s work! 


Whea the user has completed and entered some menus, the system 
asks him to confirm his entries by repeating "enter". Some 
additional information may be displayed so that the user can be 
quite sure that his entries are correct. 
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IFS2680 - ENVIRONMENT DESIGN 


The environment file contains all the information required to con- 
trol the printing of data:- 


1 - Physical page information: 
Paper dimensions 
Number of copies of each page to be printed 


2 - Print formatting information: = 
Location and dimensions of printing areas on a physical page. 
These printing areas are called logical pages. 
Names of forms on which data is to be printed. Each form 
must be attached toa logical page. 
The positioning of a form on a logical page may be 
done manually by indicating the distances from the 
top and left band sides of the logical page or it 
may be placed automatically either in the centre of 
the page or in one of the four corners. If the form 
does not fit into the logical page, it may be scaled 
down automatically. However, if desired, the form 
may project beyond the sides of the logical page. In 
this case, no data may be written to the parts of 
the form lying outside the logical page boundary. 


Vertical ipbemrsd control for each logical page 
Printing direction (orientation) on a logical page 
Up to thirty-two different logical pages containing 
two forms each may be specified. However, there is 
a limit of 18 different forms which can be printed 
on a physical page. 


3 - Typeface information for printing data: 
Character font name 
Character font size 
Character font orientation 


Up to thirty-two character sets may be specified 
withis an environment file. Each orientation and 
size of a character font is declared as a different 
character set. Logos, signatures and other artwork 
can be specified to be character sets and may thus 
be printed out as data. 


INITIALISATION 


If the user wishes to make use of most or all of the features of 

a standard environment file present in the system or of one of his 
own environment files, this may be specified on the Initialisation 
Menu. The desired features are then copied from one environment 
file to the one that the user is constructing. 


Among the standard environment files in the 
system, there are several which may be used 
for automatic 2:1 or 4:1 reduction of data. 
This is especially useful for storing large 
amounts of computer output in archives. 
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MULTI-COPY FORMS 


There is a special menu for specifying multi-copy forms which are 
intended to simulate the use of carbon paper with each copy consisting 

of a different form for distribution to different people. With this 

menu, one can indicate two forms to be printed on each copy. Up to eight 
different copies may be specified - each containing two different 

forms while the data printed on each form will be the same. It is of 
course possible to blank out data on certain forms by specifying 

black boxes within the forms. 


COMPILATION 


When all desired parameters have been entered into the environment 
file, they must be compiled so that they can be downloaded to the 
HP2680A in a form that can be used directly for printing. The com- 
pilation of the environment file is started by a command in the 

main menu. 
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IDSFORM - FORMS DESIGN 


Forms which are used for printing data on the Laser Printer are 
stored in standard MPE forms files. Each forms file may contain 
different named forms. 


The IDSFORM programme is used for. interactive forms design using only 
an HP graphics terminal. For ease of development and modification, 
each form may be have a structure consisting of: 


1 - Subforms 
Sub-forms may be stored in a temporary "Hold" file and may be 
moved or copied to other locations on the same form or even 
to other forms. 


2 - Fields which are used for printing data and for specifying 
headings. Fields must be contained within sub-forms. 


Headings may be specified using any desired character sets 
in any one of the four possible crientations and in various 
sizes. In addition, the position of a heading within the 
field may be specified as well as whether it is to be 
justified or not. Any logo cr special characters stored 

by the user may be specified in a heading. 


3 - Subfields which may be used for printing data. They must be 
contained within fields. 


FORM GRAPHICS 


When working at the form and sub-form levels, it is possible to make 
use of some graphics features: 

1 - Line drawing using 3 different line thicknesses and 8 types. 

2 - Box drawing using 3 different outline thicknesses and 8 types. 

3 - Box shading in 5 different shades 
Some examples of the variations possible in drawing lines and boxes 
are shown opposite. 


DESIGN AIDS 


A grid with numbered lines can be specified by the user in order to 
be able to place form elements at precisely the location he requires. 
This grid is purely a design aid and is not printed on the final 
version of the form. 
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IDSCHAR - CHARACTER SET DESIGN 


Characters, logos and other artwork used for printing on the Laser 
bry = stored in standard MPE files. Two file types may be 
specified: 


1 - Character Set Files: each of these files is used for a com- 
plete typeface ie. all sizes and orientations of each charac- 
ter are stored in a character set file. 


2 - Logo Files: each of these is used to store a particular logo 
or piece of artwork in all of the desired sizes. 


IDSCHAR is the programme used for the interactive creation of charac- 
ter sets and design elements by means of an HP graphics terminal and 
an HP digitiser or graphics tablet. The basic storage unit of a 

character set or logo is the character cell. 


CHARACTER CELL SPECIFICATIONS 


1 - Cell dimensions (maximum size is 255 x 255 printing dots 
te. 3.6 em or 1.4 inches square) 


2 - If proportional spacing is to be used for printing 
3 - The bounds used for proportional spacing 
4 ~ Positioning of the cell relative to other cells when printing. 


PROPORTIONAL SPACING 


Character sets may be defined as being proportionally spaced ie. the 
printing position of a character on a line depends on the width of the 
previous character. For instance, in the final printout, the space 
takern up by an "3" will be much less than that taken up by a "w". 
Within a character cell, the bounds used for proportional spacing 
may be specified. 


DESIGN AIDS 


Outline Generation: 

In order to simplify the task of designing characters, logos, sig- 
natures etc, an HP digitiser or graphics tablet may be used to trace 
the outline of a piece of artwork. Within IDSCHAR, this outline may 
be stored, magnified or moved within a character cell. If 

the user is satisfied with the outline, he may fill it in manually or 
automatically with printable dots. 
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Cell Grid: 
For the accurate placement of printing dots within a cell, the dot 
positions can be marked automatically using a two letter command. 


Cell Manipulation: 
When designing for instance a character set, a very useful feature 
of the system is the possibility to move character cells around the 
screen and to display different character cells at the same time. 
Cell Graphics: 

Using the function keys on the terminal, 

it is possible to draw lines, arcs, circles 

and boxes within a character cell as shown 

here on the right 


Examples of Character Design: 


Cj 
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PROGRAMMATIC CONTROL 


Under MPE, various intrinsics have been implemented to allow the 
user complete flexibility in controlling data printout. A programme 
called Translator (available in the Contributed Library) simplifies 

the use of these intrinsics to allow even the non-programmer access to 
the features of the Laser Printing System. 


PHYSICAL PAGE CONTROL 


A skip to a new physical page may be carried out at any time during 
the printing of the data using an intrinsic. 


LOGICAL PAGE CONTROL 


Up to thirty-two logical pages may be specified per physical page; a 
logical page may be either active or inactive. The data coming from 

a source file or programme is printed on each active logical page in 
sequence. When all active logical pages have been printed on, print- 
ing continues on the first active logical page of the next physical 

page. Logical pages may be activated or deactivated using an intrinsic. 


CHARACTER SET SELECTION 


Character set selection with an intrinsic is done by specifying the 
primary and secondary character sets. As with an ordinary printer, 
data is normally printed with the specified primary character set but 
after a shift out, the secondary character set is used for printing. 


DATA DIRECTING 


Data can be directed to print out on a particular named field of a 
specified sub-form within a selected form. The exact destination 

of the data may be specified using three intrinsics. One advantage 

of this system over traditional printing methods is that changes 

can be made to the form without making any changes to the appli- 
caions programme producing the data - the named forms, sub-forms 
and fields are all the parameters that are required. 


PEN CONTROL 


The laser in the HP2680A can be considered to be a pen drawing an 
image on the paper. This pen can be moved about and positioned any- 
where on the paper using intrinsics. Printing of data always starts 

at the current pen position. 
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OBTAINING PRINTING INFORMATION 


Several intrinsics can be used to obtain information on the following: 


1 - The character fonts in use 

2 - The logical pages in use 

3 ~- The current state of the print job 

4 - The width of a given character string in dots 
§ - Error information. 


GLOSSARY 


An MPE file containing character cells 1e. charac- 
ters, company logos, signatures and other graphics 
elements. 


Cell File: 


Character Cell: Storage unit within a cell file which contains a 
character, logo or signature etc of a particular 
font, size and orientation. 


Dots: Since the HP2680A printer prints dot patterns, cell 
size for instance may be specified in terms of dots 
(180 dots per inch or 71 dots per centimetre). 


Environment File: An MPE file containing all the information re- 
quired for the printing out of formatted data 
together with any desired forms. 


Forms File: This is an MPE file containing one or more forms. 

Logical Page: This is a printing area defined on a physical 

page which is used for printing data and forms. 

Multi-copy Forms: This is a feature simulating the use of carbon 
paper in sending the same data on different forms 
to different recepients. 


This is the term used in the printing industry in- 
dicating type size. Asa general rule, there are 

70 points per inch but the exact point size of a 
character also depends on some other factors apart 
from the height of the letter. 


Point Size: 


Proportional Spacing: Variable spacing between letters depending on 
the actual width of each individual letter. 
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CONCLUSION 


For the user who wishes only to print out a report or a memo on the Laser 
Printer the task is made easy by the use of default values available 

within the system while the user who wishes to make use of all the fea- 
tures of the Laser Printer is enabled to do so by the great flexibility 

of the software. 


31st August 1981 Anthony Stieber 


BGD, Peripherals Group, Boeblingen 
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Occasionally sales representatives of mainfrane manufacturers 
state that asynchronous communication systems are nowadays 
abolished and they refer convincingly to their intelligent 
and synchronous TP-systems. Some users accept this infornm- 
ation and spread it out with firm belief as their own opinion. 
No wonder that asynchronous communications have been more 


or less condemned. 


However, the fact is that asynchronous communications with 
means of data concentrators provide the minicomputer user 

with significant advantages regarding error correction and 
transmission performance like the IBM users with an IBM 3270 
or IBM 7380 system. This paper is aimed to help you to under- 
stand the advantages of using data concentrators specifically 


with regard to price-/performance ratio. 


Before microcomputer-driven data concentrators became avail- 
able, mincomputer users planning to install more than one 
low-speed terminal in a remote branch location had to lease 
a telephone line with two modems for each terminal at high 


cost (Pig.1ta). 
teeS2 
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Fig. 1. Two approaches to linking multiple terminals to a 
central computer: (a) using a separate line for each 
terminal and (b) using a single multiplexed line. 


Most PTT organisations provide for asynchronous modems 
only two alternatives: 
1. a modem for 300 baud ( 30 characters/sec.) 


2. a modem for 1200 baud (120 characters/sec. ) 


These low speeds do surely not encourage to operate with 
more than one CRT or printer - since, even with 1200 baud, 
to fill on CRT screen takes 16 seconds. The unsatisfying 
transmission speed in conjunction with the lack of error 


correction has carried asynchronous communications into a 


dead end. 


Another alternative was to use time-division (TDM) or 
requency division (FDM) multiplexers that enable terminals 

to share a telephone line (Fig. 1b). However, the lack of 
sophisticated error-control routines inherent in minicon- 
puter-supported Teletype-compatible CRTs, printers, and other 
remote peripherals results in unacceptable line-error rates 


with this approach. 
c<af 3 
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The error rate problem is especially acute with high-speed 
time division multiplexers that operate at the maximum rate 
for a single voice-grade-circuit. The best errer rate quoted 
by any supplier, including the telephone companies, is 107°, 
This translates to one error every 90 seconds at 9600 bps; 

at 4800 bps, one error every three minutes; and at 2400 bps - 
the minimum line speed required to fill a CRT screen in a 


tolerable time frame - one error every six minutes. 


This error rate is overcome when multiplexed data communic- 
ation networks use mainframe processors as hosts because 

the terminals automatically retransmit data contamning errors. 
As a result, mainframe terminal operators see only a slight 
degradation, if any at all, in terminal response when an 
error occurs. However, when terminals are linked to a mini- 
computer, erroneous data blocks cannot be retransmitted. 
Moreover, implementing a data communications link based on 
TDMs and minicomputers can be expensive. Modems needed to 
operate at 9600 bps can cost as much as $ 5000 each, or more 
than three times the cost of a multiplexer alone. Even at 


slower speeds, this equipment is costly. 


The need for intelligence 

To implement a multiplexed multi-terminal network, mini 
users need "smart" multiplexers that will enable them to 
hang more than one terminal off a single line at each site 
while providing the error-control required for efficient 
operation. In addition, minicomputer users need to use 
high-speed terminals to minimize operator waiting time 


during interaction with the computer. 


To provide these capabilities at a price mini users can 
afford, several US companies, such as MICOM SYSTEMS, have 
introdticed microcomputer-driven data coneantrators. These 


devices typically handle four: or eight channels. 
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A multiplexed network uses two concentrators: one at the With data concentration, the aoe aps dane error rate is so 
terminal end of the phone link, the other at the host computer. low (better than 1 block in 10") that data transmission is 
Both devices are linked to the telephone line via modems. error-free for all practical purposes. The error-handling 


In operation, the concentrators buffer data prior to trans- does not involve the host minicomputer at all. In fact, in 
mission, enabling them to transmit variable-length data most applications, the mini treats the data communications 
blocks depending on the loading on each terminal's channel. hardware as if it were simply a hardwired peripheral located 


in the same roon. 


In effect, the data concentrator, or statistical multiplexer, 

as it is often called, increases the average traffic on a The microcomputer based intelligence of a statistical multi- 

high-speed line by buffering peak traffic on individual plexer is also used to simplify network configuration. The 

eHannele. Micom Micro 800, for example, is self-configuring to a large 
extent. All configuration parameters, including the data 


The concentration made possible by buffering data also in- rates for each channel, are switch selected, with only 16 DIP 


creases throughput compared to time-division multiplexers. switches required to configure a four-channel unit. In con- 


The reason? TDMs transmit data blocks even when a particular trast, most TDMs have literally thousands of possible strap- 


terminal has no data to send. Statistical multiplexers, on option permutations, any of which may be responsible for 


the other hand, assign channel capacity dynamically accord- time-consuming installation problems. 


ing to the load on a given input channel. 
To further simplify system configuration, switch selection 


The load-averaging method used by statistical multiplexers of configuration parameters is required only at the computer 


makes them better suited than TDMs to the interactive mode site. The host data concentrator automatically down-line 


of operation that characterizes minicmputer-based systems. loads all configuration data. Only one switch need be set 


In interactive applications, the loadings tend to come in in the remote concentrator to inform the unit that it is 


id Lid 
bursts, rather than at the steady pace characteristic of a “slave"™ unit. 


batch or remote job entry. Hence, TDMs are often too power- 


ful for minicomputer applications. Data concentrators do have a drawback, however. During pro- 


longed peak transmission periods, or because lines errors 


Smart means no error have lead to excessive retransmission, “buffer overflow" may 


Moreover, by buffering data, concentrators can also check occur as data comes into the buffer faster than it can be 


data blocks received on the high-speed link and request sent out onto the line. In such a situation, data is lost, 


retransmission in case of error. To implement this automatic- with the most active channel losing all its data first, 


ally, similar to that used in IBM's SDLC protocol. A data followed by less active channels in order to buffer utilization. 


concentrator, for example, typically attaches a cyclic 
redundancy check (CRC) character to each transmitted block. To minimize data loss caused by buffer overflow, data con- 


The receiving concentrator then recalculates the attached centrators incorporate switch-selectable options intended 


CRC to check the block for errors. 
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to suspend data transmission temporarily. For example, the 
Micro800 takes advantage of the fact that most minicomputers 
will suspend transmission either on receipt of a special 
control character (XOFF), or on the dropping of the Clear- 
to-Send interface control signal. Transmission will resume 
when the system receives the XON control character or when 


Clear-to-Send is raised. 


If buffer overflow continues and data is lost, an appropriate 
message is sent to the affected terminal. The Micro800 also 
automatically transmits a "LINK DOWN" message, when the 
communications link between Micro800s is down. In short, 

the concentrator advises terminal users of fault conditions 


in the communications system. 


In the meantime Micom has installed more than 20.000 
Micro800's, many used as terminal ‘cluster controllers’ in 
DEC, Data General, and Hewlett-Packard systems. For many 

of the thousands of customers already using the first 
generation Micro800 Data Concentrator besides the easy "do- 
it-yourself installation" the most remarkable feature was 


the "do-it-yourself troubleshooting”. 


Do-it-yourself Troubleshooting 

Any item of data communications equipment such as the Micro8s00 
data concentrator must be connected to a variety of equipment 
supplied by other vendors (modems, lines, data terminal 
equipment), all of which can and will malfunction from time 

to time. Since the Micro800 is designed for do-ityourself 
installation, it also incorporates built-in test features 


to facilitate do-it-yourself troubleshooting. 


The intelligence of the Micro800 is used, for example, to 
provide the response "LINK DOWN" automatically from the 
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slave Micro800 if an ENQ (Control E) is entered from the 
terminal and the high-speed communications link between 
Micro800's is down. Thus, the terminal user is kept advised 


of fault conditions in the communications systen. 


Controls and Indicators 

The Micro800 includes as standard a comprehensive set of 
status displays and a thumbwheel switch behind the Micro800 
front panel. The 3-position thumbwheel switch provides for 
activation of two fault-isolation loopback tests and a self- 


test of the local Micro8sg00O unit. 


The Local Composite Loopback test position causes the composite 
output from the Micro8sg00 to be looped back to itself for test- 


ing of the local concentrator. 


The Remote Composite Loopback test position causes the comp- 
osite interface loopback test to be performed remotely to 
test both the local concentrator and the transmission link 


to the remote concentrator. 
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TACT Option 

The Micro800's most powerful built-in test feature is TACT, 
the Terminal-Activated Channel Test Option. TACT allows 
any terminal to check out its own operation, or the local 


Micro800, or the complete Micro800 system end-to-end. 


TACT is activated from the terminal by depressing ENQ 

(Control E), followed by BREAK. This causes the local Micro800 
to respond with the message "MICOM IN TACT". The terminal 
may now select one of four test functions. Depressing "L" 
(Local Test) causes the channel to enter the Local Channel 
Loopback mode. Upon entering this mode, the message “LOCAL 
TEST" is transmitted to the terminal. Thereafter all data 
entered from the terminal will be looped back to the terminal 
by the local Micro800. Depressing "R" (Remote Test), follow- 
ing TACT activation, causes the channel in the remote Micro800 
to enter the Remote Channel Loopback mode. The message “REMOTE 
TEST” is transmitted to the terminal. Thereafter all data 
entered from the terminal will be looped back to the terminal 
by the remote Micro8s00. 


Activation of the built-in "fox message generator" is achieved 
in the same manner as the loopback mode selection. Depressing 
“T° (Terminal Test), following TACT activation, causes the 
local Micro800 to transmit the message "TERMINAL TEST" follow- 
ed by a continuous “fox” message to the terminal. Depress- 

ing “S" (System Test) following TACT activation causes the 
local Micro800 to place the remote Micro800 in Remote Channel 
Loopback mode and transmit the "fox" message continuously 

to the remote Micro800 where it is looped back and trans- 
mitted to the terminal. The message "SYSTEM TEST" is received 
by the terminal at the start of the test. 


TACT is deactivated by depressing BREAK. TACT sionals it has 


been deactivated by transmitting the message "MICOM TACT 
COMPLETE* to the terminal. 
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For Hewlett-Packard-users MICOM provides special support 
for hp-3000 systems. Thus special XON/XOFF characters are 


being recognized for buffer and flow control. 


Introducing the Micro800/2 

Based on the experience with their worldwide installations 
MICOM has now introduced the model Micro800/2, the first 
second generation data concentrator. Besides the features 
already mentioned the Micro800/2 exploits new advances in 
semiconductor technology to offer eight times the perforn- 
ance Of the original Micro800. For example the eight channel- 
unit can handle eight (8) CRTs with 9600 bps each over one 
single modem line with 9600 bps. That means a concentration 
factor of 800 %. In addition, it offers major feature 
improvements such as data compression, terminal priority, 
terminal-initiated channel configuration, synchronous and 
clocked asynchronous channels, and a ‘command port’ to permit 
On-line system testing, reconfiguration, message broadcast, 
and performance monitoring. The Micro800/2 retains the same 
small size and light weight as the Micro800 to minimize 
logistics problems and simplify installation and replace- 
ment in the field. Like the Micro800, it is designed for 
‘do-it-yourself installation” and ease of operation by non- 


technical personnel. 


Command Port Feature 

All standard Micro800/2 models are equipped with a Command 
Port which offers a wide variety of monitoring, test, and 
control facilities. The Command Port may be connected to 

a dial-up or dedicated terminal provided by the customer or 


directly to a computer port, and may operate at up to 1200 bps. 


Message Broadcast permits a message to be transmitted from 
the Command Port to selected channels or to all channels, 
local or remote. This feature may be used, for example, to 


advise of an impending computer shut-down or the schedule 
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for system restoral. 


Dynamic Channel Reconfiguration permits the data rate to be 
changed for a selected channel or permits activation of local 
echo or generation of specific delays for carriage return, 
line feed, and form feed, temporarily overriding the channel 


configuration selected by DIP switches. 


Remote Busy permits busy-out of dial up modems attached to 
individual channels on the remote Micro800/2, facilitating 


centralized access control in timesharing computer systems. 


Centralized Troubleshooting is available from the Command 
Port, including the full capabilities of TACT as well as 


control of local and remote composite loopbacks. 


Alarm Messages with time and date of occurence are generated 
automatically each time the Micro800/2 locally or remotely 
experiences a buffer-full or buffer-overflow condition, 
encounters unusually high line error rates, or loses synchron-~ 
ization or ‘carrier’ on the high-speed composite data link. 
Analysis of the message log helps pinpoint telephone line 


and modem problems. 


Periodic Reports at user-selectable intervals or on demand 
provide statistics on data traffic, average and peak buffer 
memory utilization by channel, block retransmissions, and 
telephone line quality including outages. Analysis of these 
statistics shows trends in telephone line quality and provides 
an indication of the ability to add additional channels or 
increase the speed of existing channels to improve service 


and plan for future growth. 
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SYNC-Option 

Forthermore, I like to mention the Sync-Option. In addition 

to the asynchronous terminals it allows to operate four 
synchronous CRTs or printers. They may either run in character- 
oriented protocols (BSC) or bit-oriented protocols (HDLC/ 
SDLC). 


I am confident that I have been able to express to you the 
benefits of using data concentrators since they provide 
enormous savings in terms of telephone line and modem costs. 
As carried out in my example of a cluster-configuration 
with 8 terminals you will need - instead of 8 expensive 
telephone lines and 16 modems - one telephone line and two 
modems only. At the same time you can use fast synchronous 
modems up to 9600 bps instead of asynchronous low speed modems 
with maximum 1200 baud only. Automatically, you will have 
gained an error correction which reduces transmission errors 
practically to zero. Besides this, all these advantages 

do not load up your minicomputer system. No hard- or soft- 


ware-changes are required. 


Nowadays, since savings are more and more becoming a must, 
the usage of data concentrators is the ideal and most effect- 
ive tool for cost reduction. Therefore, data concentrators 


should be considered in any data communications concept. 
Asynchronous communications supported by data concentrators 
are by no means old-fashioned but state-of-art technology 


with progressive means of cost savings. 


Due to the high compression technique telephone lines will be 


more efficient and transmission will become error-free. 
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The purpose of this paper is to present @ new concept 
in the way in which data processing is done within any organ- 
ization which presently utilizes a central mainframe computer 
with terminal access distributed between many users. 

The term distributed processing has had various meanings 
through the development history of different computers. One 
meaning that might be attached to the term is that which also 
might be called array processing. This involves an array of 
processors distributing the power of the CPU and performing 
tasks in parallel to accomplish the computation in a shorter 
period of time. This is definitely not the meaning that I 
wish to attach to the term distributed processing. 

For the purpose of this discussion, the following phrases 
characterize ‘distributed processing’: 


-~ localization of some computational power and program memory 


Page 1 


Ql 2 


- maintenance of a central node for computation and data base 
- minimization of datacommunication traffic 

~- utilization of the relative strengths of distributed CPUs 

- maintenance of privacy by means of local data bases 

- utility of shared central mass storage and peripherals 


- concept of synergy of "one man - one machine" 


This definition warrants an easily understood clarification, 
as the concepts are more easily grasped with the presentation 
of a concrete example. The distributed processing referred to 
is that which is achieved by clustering together a group of 
what has been termed ‘personal computers! around a central node 
consisting of a mainframe CPU. Unlike the simple terminal 
interface to a central CPU which has been prevalent, this con- 
figuration leads to clear advances in price, utility, performance 
security, etc. Before proceeding, the terms personal computer 
and mainframe CPU need clarification. 

The mainframe computer was the first result of constructing 
electronic devices to perform large amounts of computation or 
calculation. Prior to the late 1930's and the early 1940's, 
rudimentary machines had been constructed to handle either 
calculation with numbers or some other sorting or controlling 
function. In order to handle problems which involved extreme 
efforts of mental and hand calculation, investigations were begun 
into constructing an electronic machine which would automate 
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the calculation process. Perhaps one of the most famous examples 
were the calculations to produce a book containing tables of 
artillery projectile paths under varying conditions of shell mass 
size, charge mass and volatility, wind conditions, atmospheric 
density and of course barrel elevation and azimuth. As 
so many variables were involved and such great accuracy 
was desired, it was necessary to perform many hundreds of 
thousands of calculations to produce a satisfactory result. 
This example serves well in showing the emergence of the 
mainframe computer for two reasons: 
- the machine was constructed largely for a single purpose, 
to perform large numbers of similar calculations 
- it was technilogically impossible to produce a computer 
capable enough, portable enough, and in great enough 
numbers to couple them directly with the artillery units 
to produce real-time computation 
The artillery projectile computer project was successful 
and interest grew rapidly in performing diverse computational 
tasks. However, fundamental limitations still existed, the 
primary for this discussion being the great expense of producing 
the central processing unit and the amount of maintenance to 
keep it performing correctly. 
As the years went by great improvements were made in 
refining the CPU, however it's expense, bulk and necessary 


level of maintenance continued to justify it's name - 
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central processing unit. 

The purpose of this immediate topic is to stress that 
the computational structure of the mainframe developed 
not due to its inherent suitability for the jb, but due 
to technological limitations in producing inexpensive, portable 
and reliable computational machines of enough capability 
to allow each user his own processor. Granted this limitation, 
the only practical solution required a central processor with 
multiusers timesharing the CPU through terminal ports. This 
multiuser aspect allowed sufficient utility to amortize the 
comparatively expensive CPU, and continues to be reflected 
today in the continuing drive to allow greater numbers of 
users to share the same machine, driving down the per-user 
cost of computational power. 

Turning now to defining the meaning of personal computer, 
it must be stressed that the term can produce varied opinions. 
The preferred definition here is a microprocessor-based 
processing unit with additional local program and data memory 
and some form of mass storage and I/O capability. More 
abstractly, a machine with sufficient power and utility to 
be used in a stand-alone mode with the capability of being 
programmatically altered to perform a very wide range of 
tasks. The last point is important as it is wished that 
programmable calculators be excluded, their use being too 
limited to manipulation of numbers and device control 
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The element that has made possible the personal 
computer is the large scale integration of many semicon- 
ductor devices onto monolithic chips. This has led to 
the realization of an effective processing unit which is 
inexpensive, very portable and highly reliable. 

Personal computers cost a fraction of the price of their 
computing counterparts of ten years ago, and fill the 
requirements of cost, reliability and portibility 
necessary for personal use. 

Subsequent to the emergence of the first micropro- 
cessor and the continued density improvements of RAMs 
and ROMs in the late 1960s, there emerged the use of 
these components as a replacement for large amounts 
of combinational circuitry that had previously been 
needed to perform certain electronic control functions. 
These first uses of microprocessors did not justify the 
name computer, as no means of user programmability was 
available. 

By the mid-1970s the personal computer began to emerge, 
tentatively and lacking in capability, amount of memory, 
sufficient I/O and most importantly, software. Given these 
realities, the machines generally found usage solely as 
means of technological amusement.and as a means of playing 
simple games. By the late 1970s a fundamental change had 


occurred and personal computers began to be used in serious 
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applications in science and business. 

Today, the personal computer is recognized as a cost- 
effective means of automating many previously manual 
operations. Computationally the processor is able to manage 
many demanding tasks and performs quite well in many appli- 
cations. Increasing emphasis on increasing the performance 
of the processor and lowering the cost of the necessary JT/0 
functions and peripherals continues and can be expected to 
yield new generations of increasingly cost-effective personal 


computers. 


Having discussed these two classes of computers and having 
brought their development to the present, the next issue that 
needs to be examined is where do these computers go from here? 
Will increasingly more advanced technology allow personal com- 
puters of ever increasing performance and ever lowering price 
to become so capable and affordable as to displace forever the 
mainframe? 

My perception of this question is that the answer is no, 
that the mainframe will continue to serve an important portion 
of the data processing system requirements of most organizations 
for the foreseeable future. It is important to note the restrict 
ion is made to be most organizations, and the validity of this 
restriction is easily shown as many small organizations today do 


rely only on a personal or microcomputer as their data processing 
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needs are sufficiently limited in scope as to be adequately met 
by the microcomputers and small peripherals. 

However, the characteristics of computer usage in a large 
organization are usually different. To corroborate the contentio 
that the day of the mainframes demise is not immediate, a few 
specific examples of the differences can be made and broken into 
two categories, immediate and future: 

Im mediate 
* vastly higher performance of mainframe is needed to perform 
tasks of high numerical accuracy or time consuming tasks 
* very involved and large applications require large core 
or program memory to successfully execute 
* cost effectiveness of sharing expensive mass storage 
and peripherals 
These points as to the need for the mainframe might 
possivly begin to change or weaken as the evolution of 
technology continues. However, another larger list can be 
made which will not as easily be displaced by technological 
change as they are not technology-dependent but rather are 
a fundamentally desirable feature: 
Future 
* the mainframe concentrates and universalizes data 
bases which are accessed by many individuals 
* allows control of the processing functions of the 


organization to be visible and controlled by management 
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allows managerial control of the security of data bases 
makes the backup and physical security of important data 
more predictable and controllable 

removes from the hands of unskilled operators the 
necessity for determining the validity of the data 

base and the funtionality of the computer 

ensures all data processing of critical nature 

uses the same revision application 

inherently allows communication between users as 

it implies a common network 

allows access to higher levels of networking as 
mainframe serves as efficient port 

additionally, it is most probable that while technology 
will bring cheaper peripherals and memory to the personal 
computer, it will probably always do so to the mainframe 
finally, it appears that perhaps a new generation of 
supercomputer might appear using Josephson junction 
technology, but the cooling requirements will obviate the 


small size and portability of microcomputers 


organization is headed. 


The HP 125 has been designed to be the foremost personal 
computer available today. As is the case with all Hewlett 
Packard products, we like to think that the HP 125 offers 
the customer not a piece of equipment, but also what we believe 
is more fundamentally important - it is a solution. It brings 
what we believe are the typical strengths of Hewlett Packard 
to what is now a somewhat chaotic and young product area. 
Hewlett Packard has been recognized for some fundamental 
precepts by which it does business; that the satisfaction of 
the customer is most important. This is not only the correct 
attitude, it also has proven to be a good business practice 
as it has over the years built a clientele of loyal customers. 
As such, the HP 125 stresses good price/performance, 
reliability, serviceability, and presents a total solution 
composed of not just the product but also the system 
interaction and software to make the hardware investment 


meaningful. 


Enough said regarding the essentiality of the mainframe 
and the inevitability of the microcomputer. Let us now The HP 125 is structurally based upon the HP 262X terminal 
consider a pair of specific computers; the HP 3000 mainframe family, sharing some common assemblies. The terminal and CPU 
and the HP 125 personal computer. Explaining the HP 125 and portion appear outwardly much like a HP 262X terminal, with 
its interaction with the HP 3000 shows where Hewlett Packard the mass storage and peripheral devices being connected to 


believes the computational system for the medium-to-large an extended I/O panel on the rear. 
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The HP 125 combines three functional abilities 
within one package: 
* it serves as an autonomous microcomputer 
* it serves as solely a data terminal 
* it creates a synergy of use by combining the function 
of the microcomputer with the data terminal 


As a microcomputer, the HP 125 operates using the 
CP/M operating system. This operating system has 
become a defacto industry standard for use with the 
8080 or Z-80 microprocessor. To support the operating 
system, a Z-80 with 64K bytes of system RAM is used. 
This constitutes the bulk of the CPU, the only other 
significant electronics being a boot ROM to load the 
operating system from the disc connected to the 
IEEE 488 interface connector and the byte-parallel 
interface to the terminal portion of the system. 

With this relatively simple CPU, the CP/M operating 
System standardizes within the memory space the 
necessary functions like input/output, file system, 

etc. which allow applications software to be hardware 
independent. Manufacturers of hardware who desire 
to utilize the standard operating system merely 
customize those portions which are necessary to 

allow the hardware to correctly perform the hardware 
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dependent I/O functions. 

The benefit of supporting the CP/M operating 
system is that the HP 125 then is able to directly 
run many hundreds of applications that run under CP/M. 
Applications include accounting packages, mailing list 
programs, word processing, languages, ete. with more 
applications being added to the list daily. 

One drawback of the standardized CP/M operating 
system is that the author of a generalized application 
package has had to depend upon the least common denomin- 
ator of hardware 1/0 capability. This becomes most readily 
apparent with the terminal interface. Most CP/M systems 
have been constructed by building a box to contain the 
CPU. The user then selected a terminal which he connects to 
CPU box. This of course means that the application written 
for the CP/M operating system has been forced to assume the 
least capable set of terminal features as more advanced 
features are not supported on many terminals. 

Acknowledging this shortcoming, the HP 125 will be 
released with a great deal of specialized software, some 
of which has been customized for the superior capabilities 
of the machine by authors of existing software applications 
and some of which has been written by Hewlett Packard. 
With these two sources of software in addition to all 
generalized CP/M software, the HP 125 will bring an unprece- 
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dented amount of microcomputer software to the purchaser. 

As mentioned, the terminal portion of the HP 125 is 
a fairly advanced data terminal, utilizing softkey structure 
to access such features as the mode of logging data from 
video memory to either the integral thermal printer or 
the serial printer connected to the vo port. Softkey 
tree selection of functions now only serves to lessen the 
amounts of keystrokes necessary to select functions, but 
also serves to guide the user. 

The softkeys within the HP 125 not only have the 
inherent functions embedded within them to implement 
the terminal features, but are also user programmable 
to contain up to 80 bytes which can be used for every- 
thing from string substitution to escape Sequences 
which actuate execution of subfunctions contained in 
applications. Each user programmable softkey can be 
accessed from either a keypad stroke or an application 
program for user selection. An application or user 
programmed pneumonic label can be placed within the 
bottom two rows to correspond to each of the eight 
programmable keys. 

With these advanced terminal features, the HP 125 
offers advanced features for a CP/M stand-alone 


computer system. 
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The HP 125 maintains a separate terminal function- 
ality within its operating capabilities. When power 
is applied to the system it normally defaults to the 
terminal mode of operation, with the selection of 
loading the operating system to become a microcomputer 
being selectable by the depression of a single softkey. 
As a data terminal, the HP 125 has capabilities similar 
to those of the HP 2621, with some enhancements common 
to more advanced members of the HP 262X terminal family. 
Additionally, it presents some features not previously 
available. 

First a brief description of the terminal capabilities 
of the HP 125 before a discussion of those terminal features 
unique to it. 

As a terminal, the HP 125 presents the user with 24 
lines containing 80 characters of text. Also on the 
sereen are a 25th and 26th row containing the labels for 
either the embedded softkey tree structure, or when 
selected, the user programmable softkey pneumonics. 
The terminal allows selection of half-bright, underline, 
inverse video, or blinking enhancements on a line-to-line 
basis. 

The keyboard is the full extended keyboard which contains 
dedicated cursor control, scrolling, softkey, numeric pad, 


and screen-oriented editing keys. 
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Input/output is provided by an IEEE 488 port and two 
serial ports. One serial port is nominally dedicated to a 
serial printer, the other to datacom munications. 

Datacomm runs at 9600 baud and supports various handshakes 
necessary for use with different CPUs and modems. The datacomm 
port also supports the 13265A direct-connect modem. The printer 
port is configurable for variable amounts of nulls, parity, and 
the sense of the rate-pacing handshake. This allows the HP 125 
to directly use a large amount of serial printers without the 
necessity of any special logic or cables. 

As an option, the HP 125 supports a thermal printer which is 
integrated into the top of the terminal package. Either this 
printer or a serial printer (if configured) are supported within 
terminal firmware by a softkey tree which allows the direct 
printing of the entire contents of video memory, the visible 
screen or a Selected line. Additionally, logging modes can be 
Set so that all data coming to the video memory or only that 
data overflowing video memory is printed. 

All configuration information is stored in a CMOS RAM 
which has battery backup, allowing the user-selected confi- 
guration to be maintained when the system is powered down. 

The terminal supports remote operation and configuration 
‘ by use of escape sequences. As an example, the keyboard has 
a ‘home cursor' key which positions the cursor at the first 


character in video memory. An application program can also 
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home the cursor by transmitting the correct escape sequence 
to the terminal. By this means, applications running in either 
the CP/M CPU within the system or an application running on 

a mainframe can efficiently manipulate the terminal features to 
provide a friendly applications interface to the user. 

The afore described features make the terminal portion of 
the HP 125 a high performance terminal for use with both the 
CP/M CPU and when used with a remote mainframe. These features 
are fairly comparable to those which are Supported within the 
HP 262X family. 

Additional to these, the terminal implements several unique 
features which are fundamental for its use as a CP/M terminal 
interface and which also generally provide better performance. 

Within the terminal, an I/O map is maintained which allows 
the mapping of any source devices to any destination devices. 
(For the purpose of this discussion, note the terminal considers 
the output of the CP/M processor to be an input!) An example 
may better illustrate this: 

In order to diagnose a difficulty in running @ CP/M-based 
application, the HP 125 user can map the output (console out) 
of the CP/M CPU to be not only the CRT screen, but also datacomm 
port 1. To this port he has connected a modem which ties over 
the phone lines to another HP 125 (or terminal) on which a 
knowledgeable user of the application is viewing. By this means, 


the output of the application and keystrokes entered by the 
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user (CP/M operates in a full duplex mode) can be viewed for 
debugging. Further, were the user to map datacomm port 1 as 
the input for the CP/M CPU (console in), the remote viewer can 
also run the program and allow the direct operator to watch 
in order to learn the correct manner in which to run the 
application. 

As another example of the value of this feature, 
consider a CP/M application written to perform an 
accounting function. Within the application, various 
output is routed to either the screen or to the printer 
for hardcopy. Often it is desired that this fixed 
output routing be altered, perhaps to obtain hardcopy 
of items normally sent to the screen. With the HP 125 
I/O map, this is easily accomplished. 

Another distinctive feature of the HP 125 is that 
all the ROM-based routines which give the terminal 
portion of the product its capabilities are vectored 
through locations in RAM upon powering the system on. 
By this means, an application which doesn't prefer to 
use the terminal capabilities as dictated by the ROM 
routines can intercept the routine call and substitute 
in RAM its own specialized routine. An example of this 
ability is also illustrative: 

In the normal mode of operation, the cursor control 


and editing keys as supported by terminal firmware allow 
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the user to manipulate the text on the screen directly. 
However, this 'feature' may not be desirable while in the 
midst of running an application. The application can 
consequently be written to intercept the keystroke process- 
ing routine and can then trap keystrokes which are extra- 
neous to the application previous to returning control to 
the terminal ROM code for keystroke execution. Or by this 
means, the functionality of keys can be altered. 

By this method of embedding a high degree of functional 
capability in ROM but yet allowing customization of routines 
critical to certain applications, the HP 125 goes well 
beyond the capabilities of most microcomputers. Very 
sophisticated terminal features are ROM resident, and special- 


ized features are application programmable. 


Understanding the HP 125 from the physical and features 
standpoint allows us now to address the unique capability 
that Hewlett Packard brings to the field of making distributed 
processing an asset for organizations with large and diverse 
computing needs. 

In a previous section, the permanent and essential 
nature of the mainframe was discussed. AS present users 
of the HP 3000 computer can probably attest, a majr 
usage of the system involves the creation, maintenance 


and access to data bases which allow the smooth function- 
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ing of large organizations. This automation of data 
base with instant and accurate access has been the principle 
benefit of the computer to the business world. 

Granted that the personal computer and the mainframe 
have been discussed and the individual merits of both are 
appreciated, an examination of the interaction of the 
two for doing distributed processing is appropriate. 

Personal computers have begun to appear within the 
ranks of large organizations for use either by individuals 
or for the needs of a small department. While the personal 
computer has obviously fulfilled a purpose, the utilization 
factor could be greatly larger. The HP 125 performs well the 
tasks being addressed by the personal computer, but brings 
much greater utilization without a greatly appreciable higher 
price. 

The function that is easily recognized for a personal 
computer within a large organization is what may be called 
data display and analysis. This term is meant to describe 
the typical interaction of a manager with those performance 
criteria of his organization represented by a collection of 
data. 

For the display and analysis of data, the personal 
computer of today tends to fail to efficiently perform its 
function. The data base for most organizations is large, 
communal in nature, subject to frequent correction or update, 
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and most necessarily must be current and correct throughout 
the organization. Using a stand-alone personal computer, 
much time consuming and detailed analysis has been done 
only to find the raw data was incorrect due to an error 

in transcription or a recent update. 

Additionally, most information within organizations comes 
from a multitude of sources. Using a typical division within 
Hewlett Packard as an example, data bases are maintained that 
updated or accessed by accounting, personnel, purchasing, 
Scheduling, manufacturing, quality assurance, research & devel- 
opment, administration, etc. This is the data that is the 
subject of display and analysis. 

With todays typical personal computer, the transfer of data 
between the micro and the mainframe is at best tedious if not 
impossible or prone to error. The HP 125 strives to make this 
process the most expedient, error-free and simple process 
possible. With a wealth of data base management capability 
available on the HP 3000 computer, the HP 125 leverages great 
power into the hands of the person who analyzes or updates 
the data base. 

As an example, the HP 125 supports a screen-oriented 
calculator which allows management personnel to easily 
create, display and manipulate data. It allows the manager 
to quickly explore "what if" questions regarding the vital 
numerical data which represents his success or failure. 
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Additionally the HP 125 supports a graphical display package 
which allows significant data to be displayed by means of 
bar charts, pie charts, etc. With the HP 125, the data for 
display, analysis and charting can interactively flow over 

the terminal data comm port to and from the personal computer 
and the mainframe. All data is from the common base of the 
mainframe and represents the organizations most recent and 
accurate figures. All results of analysis can immediately 

be re-entered into the common data base. Standardized 
reports from functional areas can access the database from 
other areas in which they don't necessarily have involvement 
as to the generation of data, but from which their respective 
areas can be directly affected. 

All functional areas can present reports that are stan- 
dardized across the organization as to format. Data flows 
efficiently between organizations, as data entered by one 
area becomes immediately accessible for all users. The 
security of the data base is cared for by the information 
services group, guaranteeing against the hazards of losing 
critical data. The access of individuals to data is 
controlled by management; the HP 125 can be programmed to 
allow only visual display of the data without user 
copying to printer or disc while the initial access can 
be protected by the HP 3000 using passwords. 

The strength of the HP 125 is its interactive ability 
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to dynamically perform as a port to the mainframe, a 
stand-alone personal computer, or a synthesis of the two 
functions. Stressing the dual nature of mainframe access 
for data interchange with local analysis, the HP 125 features 
utility programs which greatly simplify the user interface 
and lessen the need for sophistication in performing complex 
or powerful analysis of mainframe data. 

As an example, take the purchasing department in a large 
organization. One of the areas with the greatest potential 
for cost minimization is the timely and careful control of 
inventory. Suppose that this organization does basic manufact- 
uring of a wide line of products with many subcomponents and 
consequently has fifty buyers interacting with a thousand 
vendors regarding tens of thousands of purchased parts. 

Due to the common and large data base needed to track the 
tens of thousands of parts, the HP 3000 presents a good choice 
for a central mainframe, probably also functioning for other 
purposes within the organization. By utilizing the HP 125 
as a personal tool for each of the fifty buyers, an extremely 
powerful controlling application can be quickly written for 
use by each of the buyers. 

Organizing the overall data base using the HP 3000 and 
IMAGE, the HP 125 can be used serve as the user interface 
into the larger database for each user. Data is taken from 
the mainframe into each of the fifty buyers personal computers. 
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The data resides locally and is manipulated by each buyer for 
programmed action items such as overdue shipments, low invent- 
ory items, high inventory items, changes in scheduling 
affecting inventory needs, etc. Purchasing management can 
control and standardize the means of analysis of each 
buyers proficiency through a common local program. Each 
buyer using his own data base can generate reports with 
a common format with all buyers reports. Using the 
HP 125 graphical package to generate bar or pie charts, 
the performance indicators can be directly analyzed and 
evaluated. 

In this example, the HP 125 served as the individuals 
port to the HP 3000 data base, it performed local analysis 
of data, reduced datacomm overhead and expense, and allowed 


local generation of reports and graphical analysis. 


To summarize, it is believed that the manner in which 
computers are used by organizations to enter, display and 
analyze data is evolving towards a new distributed network 
of processing units. The change on the scene is due to the 
technological ability to produce processing units that are 
inexpensive, reliable and capable. The ability to place 
a personal computer in the hands of an individual has shown 
to be not only cost effective, but by being personal has 
involved individuals not previously utilizing computing 
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power directly. While personal computers have these 
benefits, they have not fully utilized the greater 
advantage of being part of the entire organizational 
data processing network within most organizations. 

The HP 125 used with the HP 3000 shows the first 
step in the evolution of data processing. This evolution 
will bring computer usage into the hands of increasingly 
greater amounts of individuals within organizations. 
Data processing will become more convenient and cost 


effective. 
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TERMINAL 1/0 TERMINAL 1/0 


AN ENGINEERING FEEDBACK SESSION 


AN ENGINEERING FEEDBACK SESSION 
1. SHOULD HP SUPPORT THESE FACILITIES ON FUTURE POINT-TO-POINT 
TERMINALS? 
A. HALF DUPLEX MODEMS 
Jim BEETEM B. DIFFERING INPUT/OUTPUT LINE SPEEDS 


C. PAPER TAPE MODE (TAPEMODE ) 

D. HP 2615 (MINI BEE) TERMINAL TYPE 

E. TERMINAL TYPE 11 

F, HARD COPY DEVICES WITHOUT BACKSPACEABLE CURSORS 


("REAL" TELETYPE ASR 33's) 


9. WHICH NEW TERMINAL FACILITIES WOULD BE VALUABLE FOR EUROPEN 
USERS? 


PRESENTOR 


JIM BEETEM 
INFORMATION NETWORKS DIVISION 


RHE 


####or 1 1 WAITING FOR FULL TEXT 
(EDITOR) 
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HELSINGIN KAUPPAKORKEAKOULUN LASKENTAKESKUS 
MELSINKIE SCHOOL OF FCONOMICS COMPUTER CENTRE 


DAISY /3000 


Ww R H IN TEXT PROCESSING 
Daisy 3000 - A NEW APPROAC Pp 


A NEW APPROACH IN TEXT PROCESSING Once upon a time, Mr. Gutenberg discovered typography. It was a revolution in 


information distribution. 


When IRM released the electronic typewriter with type ball and later advanced it 
Timo RauNIO by including maqnetic memory, we were talking about word processing. 


Only a few years ago did the rush of all kind of microprocessor controlled equip- 
ment with display units and floppy discs begin. Now we can use the term text 
processing, although their different features, hardware and prices cause confusion 
in our minds. 


However, now we are standing at the front door of integrated information process- 
ing, which includes all conventional data processing as well as high quality printed 
output, electronic archives, automatic reproduction and mailing, etc. A key to 
slightly open that coor is DAISY/3000, a program which fills the gap between 
your existing systems and high quality formatted output with reasonable costs, 
and meanwhile, satisfies all of vour normal text processing demands, until we 


have "the paoerless office”. 


WHAT IS DAISY/3000 


DAISY is a high level document description language with which almost any kind 
of document can easily he produced, It fully utilizes the intelligence of the 
Diablo orinter and Hyfeed sheet feeder. Over 70 hasic level’ commands are 
recognized by DAISY and these commands are used to define even higher level 
macro commands. To obtain high quality, even very complicated, formatted out- 
put, the user only inserts a few names of these previously defined macros within 
the text. 


In addition to all normal text processing features, some sophisticated capabilities, 
such as qraphics, user-written procedures, conditional execution etc.; are included. 
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COMMAND LEVELS RESTRICTIONS 
Printer level commands are escape sequences which are hard to remember and DAISY/3000 is hardware dependant. It has been written in SPL, which is known 
difficult to use. The user does not have to worry about them with DAISY. only by HP computers. Conversion to PASCAL may be possible. 

Basic level commands have mnemonic names and are much easier to use. They | The escape sequences controlling the output devices have no standards, and neither 

also qenerate all of the required escape sequences for the desired operation. do the features of printers. Therefore, only one printer could be selected as the 

However, the user seldom has to he concerned about them, unless he is the output device, so that all of the advanced formatting features and special effects 

person creating macro libraries. could be realized. Thus, formatted output is available only with the DIABLO 
printer. 


Macro level commands are the main tools used when entering texts to he format- 

ted. Macro commands are named and defined by the user. Thus, their names Even if the escape sequences could be converted, a display terminal cannot show 

and function can be desiqned according to the user's demands. all the necessary formattina. An example: A very normal situation is to have 
margins at columns 9 and 79. With proportional spacing, this area contains 
85-100 characters per line and an 80 column display will cut the line and could 


MACRO LEVEL BENEFITS not possibly show the right justified margins. 


As known in the other programming lanquages where user defined macros are 
‘ ae DAISY: COMMANDS 
available, the macros are the key to effective and structured programming. The 
same also applies to text processing and especially to flexible text entry. 
This section describes the basic level commands by classes. More detailed infor- 
j mation can he f d i "ED " . Stee 
Some noticeable benefits of macro level commands are: e found in the "DAISY reference manual" and in the application notes. 
- Short commands do a lot. Thus, complex series of commands or often used 
phrases can be referred to by a single name. 


Command classes are: 


- Define files 
- Flexibility. Just changing the macro library will result in a totally different - Define macros 
output format or changing a macro definition will have its effect throughout - Modes of operation 
the text. - Size of page 


- Vertical movement 


- Mnemonic names can be used in any lanquaqe. 
- Horizontal movement 


- Less errors. A correctly designed macro does it right always and there - Special effects 
remain only typing errors which rarely can be avoided. - Automatic titles and footnotes 
. - Graphics 
2 Less work. Once desiqned, macros can always be used. ane ; 
- Automatic table of contents and keyword index 
- The user can concentrate on WHAT he is writing, NOT HOW he is writing. - Conditional commands 
- Us d 
- No regressive way of thinking. Each macro can cancel all unwanted states ee eee Sere 
- Hyphenation 


set by other macros, Thus, each macro STARTS a block of text. ; 
- Miscellaneous 


- No need to adjust the text on the display. The user simply writes the text - End 
and the macros always do the proper formatting. - Edit 
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The commands can be located anywhere within the text and are indicated hy a 
"command character". Some commands have numeric parameters which can he 
any integer expression containing variables and constants. 


USER PROCEDURES 


If the capabilities of DAISY are not satisfactory, the user can write his own 
procedures or subprograms in SPL or FORTRAN. DAISY then loads such routines 
from the user's SL file when desired and the procedure can return commands 
and/or text for DAISY to process. 


This feature allows direct linkages to existing systems, data bases and registers. 
Also, user-written "preprocessors" for the input can easily be done to totally 
change the default syntax of commands. 


INTERACTIVE APPLICATIONS 


EDIT 


User-written procedures can be used to obtain interactive text processing applicat- 
ions. However, DAISY itself includes commands to make conversation with the 
user. 


In many cases, it is desirable to alter some of the formatting parameters during 
execution. Form size and printwheel characteristics are two such parameters. 
Also, you may have a fixed text where only a few words should be changed 
from time to time. Editing of such text is unnecessary if you use interactive 
commands. 


There are several methods to create input files or write texts for DAISY. One 
way is EDIT/3000, which as known is a very powerful tool when entering or 
editing any kind of source texts. EDIT/3000 is available in the normal way or 
as a son process of DAISY through the EDIT command. 


Although EDIT/3000 is quite a meritorious program, it lacks a few desirable 
features when entering and editing texts in human lanquages. Therefore, DAISY 
has a built-in, full-screen editor which operates in block mode and fully utilizes 
the local edit facilities of HP2640 series terminals. (2620 series terminals are 
under investigation). 
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DAISY IN PRACTICE 


When compared to those stand-alone micro-monsters, DAISY has a totally differ- 
ent theory of operation. Which one is better depencs on what you are doing. If 
you are only replacing a typewriter, DAISY may be too sophisticated. But, if 
you want real text processing, the macro level commands show their power. 
And if you are planning linkages to your existing systems or to raise your inte- 
gration level, there are not too many other possibilities available. 


EXAMPLES 


The following four pages show some examples of DAISY applications. They are 
not examples of any ordinary text processing applications which any system can 
do. Rather, they show some of the flexibility and graphical power of DAISY. 


The first example shows part of an application note which describes a convenient 
way to draw flowcharts. This macro library consists of about 30 defined macros, 
20 of which are not visible to the user. The flowchart in the example was 
drawn with 12 lines of input, using 9 of these predefined macros. 


The second example shows the usage of multiple printwheels. It was printed 
with 3 different wheels: CUBIC PS, APL and SCIENTIFIC. 


The third one is an example of multicolumn printing. 


The last one shows mathematical expressions with user-defined, special-symbol 
macros, using graphical mode. 


DAISY is developed in HELECON, HELSINKI SCHOOL OF ECONOMICS 


Distribution: Oy PORASTO Ah 
Tddldntullinkatu 8 
00250 Helsinki 25 
FINLAND 
Telex: 125194 PSTO SF 
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deleted LGLOAG 


OAISY: application note 2/81 


HOW TO MAKE FLOWCHARTS WITH DAISY 


Macrolibrary "FLOWCH" provides a convenient way to draw flowcharts. txamp- 
y Pp Y 


les 





User input defines which symbols are used and where they are located, text 
within symbols and where to draw lines. 


Daisy automatically calculates the form of symbols, horizontal and vertical cente- 
ring of the texts, start and end points of the lines, location of arrowheads, location 
of "yes/no-like" labels around the "if" symbol and the scale of the picture. 








——— = 


Runeberginkatu 14-16 SF-00100 Helsinki 19 FINLAND vn J 90-440211 
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2.2 Ensimmaisen kertaluvun predikaattikalkyyli 


Nimikkeisté L koostuu joukosta vakio- funxtio- ja predikaattisymboleja. Jo- 
kaiseen funktio ja relaatiosymboliin hittyy kokonaisluku, joka ilmaisee syrnbolin 


paikkaluvun. Tasmallisemmin, 
L = (Const, Func, Rel, ar), 
missa 


Const -- vakiosymbolicn joukko, 
Func -- funktiosymbolien joukko, 
Rel -- relaatiosymbolien joukko ja 
ar: Func U Rel > N. 


Kun ar(f) = n, f € Func, sanomme, ettai f on n-paikkainen funktiosymboll. 
Vastaavasti, kun ar(r) = n, r € Rel, sanomme, ettd r on n-paikkainen relaatio- 


symboli. 


Nimil&cistin L = (Const, Funk, Rel, ar) struktuuri on pari M = (M,I), missa 
M on ei-tyhja arvojoukko ja I on kuvaus joukolla Const ¥ Func Y Rel, siten, 


etta 


Kc) « M kun c € Const, 
if): M+ M kun f € Func, ar(f) = 9 ja 


I(r) ¢ M9 kun r € Rel, ar(r) = 1 


Kdytimme usein merkintaa cM = 1(c), (M = I(f) ja rM = I(r), 


Esimerkiksi ryhmateoriassa kdytetdan nimikkeist6a 
L, = (tol, {+},0, ar) 
missd ar(+) = 2. Ly :n struktuuri on pari M = (M1), miss (0) € M ja I(+): m2 
+ MM, 
Lukuteoriassa taas kaytetdan nimikkeistoa 
lz = ({o}, (5, +, *}, ©, ar), 


missa ar(S) = 1 ja ar(+) = ar(*) = 2 Eris timin kielen struktuuri on M = 
(M,D, missa OM =-OEN, SM (n) = nel, +M (m,n) = m+n ja *M (mn) = m*n, 


ts nailla symboleilla on standardi merkityksensa, 
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Opiskelutekniikka -3- 


Seminaariharjoitukset tapahtuvat pienryhmissa (y- 
leensd 8-15 henkiléa). Niissd kdsitellaan keskuste- 
lemalla joko teoreettisia tai kdytanndllisia kysy- 
myksid. Seminaariharjoitusten yhteydessd opiskeli- 
jat laativat usein myds esitelmia keskustelun poh- 
jaksi ja joissakin aineissa kdsitellain seminaareissa 
myds heidaén tekemiaan tutkimussuunnitelmia. Se- 
minaareissa on hyva tilaisuus oppia tieteellisen kes- 
kustelun periaatteita ja tutustua oppiaineen meto- 
diikkaan. Ne auttavat tehokkaasti syventymdan 
omaan aineeseen. 


Ei ole liioiteltua vdittaa, etta useimpien akatee- 
misten aineiden opetus on nykyadan niin tehokasta, 
etta opiskelijoiden todella kannattaa seurata sita 
niin paljon kuin mahdollista. Oppitunteihin, ko- 
keellisiin téihin ja harjoituksiin osallistuminen on 
useimmiten tentissa onnistumisen valttamatdn 
edellytys. Harjoitukset antavat tarpeellisen tai- 
don selviytyd soveltavista tenttitehtdvista, ja se- 
minaarissa saa tarkeata ohjausta tieteelliseen ty6- 
hon. 


1.3.4 Aktiivisuuden merkitys 


Ratkaisevaa on kuitenkin, etta opiskelija ei vain 
"istu" erilaisissa opetustilaisuuksissa. Ainoastaan 
osallistumalla aktiivisesti tyéskentelyyn han voi 
saada jotakin irti opetuksesta. Sen lisaéksi hadnen 
tdytyy kayttda hyvakseen jokainen tilaisuus kes- 
kusteluun opettajan kanssa ja tehdd tdlle kysy- 
myksid. Opettajat yleensd arvostavat sitd, etta 
opiskelijat seuraavat heidaén opetustaan aktiivi- 
sesti ja kiinnostuneina. 


1.4 OPINTOJEN SUUNNITTELU 


1.4.1 Pitkdn tahtayksen ohjelma 


Tarkeampia johtopdatdksid, joita voidaan tehda 
teoriaosan perusteella, on se, etta yhden ja sa- 
man aineen liian keskitetty oppiminen pitkahkén 
ajanjakson aikana tuskin on jarkevdd. Sen tah- 
den on hyva suunnitella vaihteleva pitkan ajan 
ohjelma, jotta vadltyttdisiin tehottomilta ja usein 
masentavilta oppimistasanteilta. 


Tehokkaan opiskelumetodiikan tarked apuvdline 
on siis mahdollisimman yksityiskohtainen suunni- 
telma. Pitkan tahtayksen suunnittelun on havaittu 
vaikuttavan positiivisesti opiskeluun. Jokainen saa- 
vutettu vdlitavoite antaa opiskelijalle tyydytyk- 
sen tunteen ja lisdd opiskelutarmoa auttaen siten 
voittamaan seuraavan tehtavan mukanaan tuo- 
mat alkuvaikeudet. 


Padamaaradn tulee luonnollisesti olla realistinen: 
jos on asettanut itselleen liian suuret vaatimuk- 
set - toivoen siten kannustavansa omat kykynsd 
adrimmilleen - alkaa jonkin ajan kuluttua tuntea 
haluttomuutta huomatessaan, etta padmaarda ei 
voikaan saavuttaa. Itseltddn liian vahdn vaatimi- 
nen veltostuttaa ja opiskelija oppii viela vahem- 


oO 


man kuin oli suunnitellut. Tehokkainta on asettaa 
pddmddrdnsa siten, etta sen voi tavoittaa maksi- 
maalisen ponnistelun avulla. Sen on siis oltava saa- 
vutettavissa, mutta vasta todellisen tySpanoksen 
jalkeen. Ei riita, jos suunnittelee "ehtivansd niin 
ja niin pitkdlle aineessa ensimmaisten viikkojen 
aikana". On vahintaan yhta tarkeata yrittaad suun- 
nitella ty6nsa yksityiskohdat viikko viikolta ja pdiva 
pdivadlta. 


1.4.2 Lue sopivasti 


On niinikaan hyddyllista kehittad kiinted tyds- 
kentelytapa. My6s tydskentelytapa on suunniteltava 
realistisesti siten, etta sita voidaan noudattaa 
pitkan ajanjakson kuluessa. Sen tahden on tyés- 
kentelysuunnitelmaan jatettadva tilaa esim. urhei- 
lulle, ostosmatkoille, kirjallisuudelle ja sanoma- 
lehdille, jarjest6toimintaan osallistumiselle, eloku- 
vissa ja teatterissa kdynneille ja muille virkistys- 
mahdollisuuksille. Nain valtytaan suunnitelman ali- 
tuiselta muuttelemiselta ja ennen kaikkea sddsty- 
taadn silta tunteelta, etta olisi "epdonnistuttu" hy- 
vissa aikomuksissa. Voit esimerkiksi hankkia pdi- 
ja merkita siihen suunnitelmasi. Usein on sopi- 
vinta aloittaa merkitsemalla tenttipaivat, ja si- 
ten laskea ne tenttia edeltavdt pdivat, jotka tar- 
vitsee kertaukseen ja sen jalkeen jakaa jaljella 
oleva aika niiden kurssin osien kesken, jotka tdy- 
tyy suorittaa, jotta ohjelma pitdisi paikkansa. 


Yliopistoissa ja korkeakouluissa tiettyyn jarjes- 
telmaan sidottu opetus on muotoiltu siten, etta 
se vaihtelee viikottain. Silloi on viela jokaista 
viikkoa harkittava erikseen. On kuitenkin miltei 
aina mahdollista sovittaa opiskeluty6 kiinteisiin 
aikoihin ja taten luoda itselleen tydéskentelyrutii- 
ni, jota voi noudattaa. 


1.4.3 Suunnittele yksityiskohtai- 
sesti 


Ajankayttd ei suinkaan ole ainoa asia, joka pi- 
tdd suunnitella sopivaa kaavaa noudattaen. Myds 
opittava aines tulee organisoida hyvin. Kurssin 
jokaisen osan kohdalla on suunniteltava, kuinka 
paljon aikaa kuluu kurssikirjojen, muun kirjalli- 
suuden ja luentomuistiinpanojen lukemiseen, pal- 
jonko aikaa kuluu mahdollisiin harjoitustehtaviin 
ja esitelmien laatimiseen, ia lopuksi, kuinka pal- 
jon aikaa on varattava kertaukseen ennen loppu- 
tenttid. Kertaamiseen varattu aika on usein te- 
hokkaammin kaytettyd kuin alkuperdinen oppimi- 
saika. Edelleen voi olla hyvin edullista lukea eri 
kirjoja tai kurssin kohtia rinnakkain. 


1.4.4 Realistinen paamaaria 


Akateemisten opintojen suunnittelussa on erit- 
tdin tarkeadta, ettei opiskelija yliarvioi omaa opis- 
kelukapasiteettiaan. Suhteellisen vapaa opiskelu tar- 
joaa kyll4 mahdollisuudet tahan. Monet opiskeli- 
jat aloittavat liian optimistisesti monta ainetta 
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5 The AJKA model performance 





the mean percentage mean absolute error 





M = ] ) 100 


n 1 T lait - Pit| t= Lyaseat 
(s pm 
T=1 Ait i= 1,...,n 


1 
nN j=1 


‘ 


and 


the mean percentage root mean square error 


12 VU Ait ~- Pitye t = 1,...,T 
Pec SC it)") 100 ee: 

nj=1T Vo (ait - A)e i = 1,...,n 
are used. | 


3- It is possible that an equation has a good statistical 
fit, but a poor tracking fit. This is due to the dynamic 
properties of the model which bear little relation to the 
way individual equations fit the historical data. It is for 
this reason that M and R tracking errors are an important 
criterion for the evaluation of a multi-equation model. 


4. In the following comparisons of calculated vs. observed 
variable values will be performed between the AJKA and the 
ETLA models and trend forecasts: 


1 for periods 1958-78, 1971-78 and years 1977 and 1978 
2 for 22 common endogenous variables of AJKA and ETLA 
3 for some of the most important variables separately. 


| These are documented e.g. in Johnston, H.N., Klein L.R. 
and Shinjo K.: 'Estimation and Prediction in Dynamic 
Econometric Models', Chapter 2 in Sellekaerts, and in 
Pindyck and Rubinfeld. 
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Abstract: (No more than 200 words) 


Running 28 different applications with more than 100 users situated all 
over the country, working in the automobile import and resale trade, 


and in the agricultural machine trade, forces you to design the appli- 


rer 
cations with regards to the many different opinions about what is needed 
rT 


and what is not. 
Se a eh 


This presentation will give you an idea about our philosophy on Systems 


ee SS 00S Se 


Development, on buing packages, programs or projects. 








It will present our philosophy on Real Time versus Batch processing 


and our implementation of Semi Batch tasks. (continued on next page) 


a 
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It will present our philosophy and implied problems with the use of 
IMAGE, KSAM and MPE files, and how we change a system from one 


to another — if it seems relevant. 


I will comment about our methods of squeezing more through the 
machines, how we find out which parts of the apllications are the 
bottlenecks and how we reduce the resources used in an application, 
using among other NOBUF 10, MR, blocking to sector boundaries, 


reprogram to SPL etc. 


I will comment about the various ways of handling terminal dialogs, 
and on the SL compared to stand alone programs. 

I will present a method of changing the package from a set of stand 
alone programs to one master program handling the outer routines - 
database open etc - and keeping the programs as code segments. 
(This reduces overhead from the domain of users changing from one 
program to another.) It is a result of our development strategy and 


optimization. 
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Some Problems of Software Engineering 


Wladyslaw M. Turski 
Institute of Informatics 


Warsaw University 


The phrase "software engineering" was coined just over 13 
years ago. It was considered a_ little provocative by its 
originators and was chosen explicitly for this reason. The 
group of coveners of the Garmisch (October 1968) and Rome 
(October 1969) conference sponsored by the NATO Science 
Committee deliberately selected a key phrase that contrasted 
wiht the then prevailing perception of software issues 
("software chaos" and "software crisis" being then two 
phrases very much in vogue). The phrase "software 
engineering" hinted at law and order in. an environment 
considered hopelessly anarchic, promised some rigour and 
discipline where there was none, whiffled of industrial 
approaches in the field where artisanship reigned 
unchallenged. The phrase "software engineering" evoked - no 
matter how nebulously - notions’ of standards, measures of 
productivity, industry-wide and commonly accepted codes of 
good practices. Unfortunately, the launching of a phrase 
seldom solves any real problems and sometimes creates new 


ones, primarily those of credibility. 


Q0 2 


Software engineering caught on. Conceived as an intellectual 
provocation by the mostly academic animators of the 
Garmisch-Rome conferences, the phrase was cagerly accepted 
by all sorts of industrial organisations. The younger set 
(and information processing community expands so quickly. 
that it constantly seems to consist more of the younger set.) 
is now firmly convinced that’ software engineering is a 
well-established industrial discipline, opposed or at least 
neglected by the academia. (A year ago I witnessed a most 
revealing scene: at a computer-oriented gathering on the 
antipodes, a very articulate, but clearly not’ very 
well-read, industrial programmer addressed a professor of 
computing science with a question he obviously thought 
rethoric: when at long last, would the universities 
recognise the existence of software engineering, accept the 
inevitable and start doing something useful] in this 
direction. The object of this tirade was the person who can 
justly be called the spiritus movens of the 68/69 
conferences, one of the authors of the phrase "software 
engineering". Unlike social ones, this’ technological 


revolution turned against its fathers. 


The software crisis of the 60's was very real. The quality 
of most computer programs was very poor, their documentation 
- at the very best ~ sketchy, the reusability of software 
components - practically unheard-of, software systems in use 
were growing patchier and patchier, software projects were 
notoriously behind schedule and above budget. The shortage 
of skilled programmers was crippling, good people were hard 
to get and once gotten would very often be soon bribed away. 
Programming languages were just about the only facet of 
programming sufficiently well-understood to have a 
comprehensive and consistent theory (even in this case the 
theory covered only part of the problem, i.e. syntax, 
leaving out the perhaps more important subject of 


programming language, which is semantics). 
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Ideally. software engineering should have cured all these 
and similar ills. Unfortunately these phenomena - very real 
ones - are merely symptoms of much deeper troubles and since 
most efforts directed at remedying the symptoms do not cure 
the sickness that. causes them, even if taken jointly, all 
prescriptions for ameliorating particular aspects of the 
software crisis do not seem to appreciably improve the state 
of affairs. Even though the expression "sottware crisis" is 
by now nearly forgotten, almost all the complaints made 
fifteen years ago could be repeated today, perhaps more 
strongly. There is, however, one notable and very important 
exception: we have learned how to write correct programs 


given precise specifications. 


I am fully aware that the ability to make correct programs 
given precise specifications is but. a small] consolation for 
someone faced with the full scope of issues involved in 
providing the software part of a computerised = system, 
nevertheless I am going to spend some time analysing this 


achievement. I am going to do so for several reasons: 


(i) because it shows what it takes to solve a problem 


in the area of software engineering, 


(ii) because it bares some fundamental deficiencies of 


the common sense approach to software problems, 


(iii) because it demonstrates the intellectual 
techniques involved in’ solving a methodological 


problem if software construction, 


(iv) because it is the only part of software 
engineering that can be completely discussed in 


scientific terms. 
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Let ous first consider why instcad of a simpler cxpression 
"correct program" we are using a longer (and, admit tedly. 
clumsier) one: “program correct with respect to its 


specification". 


The only” rational interpretation of the shorter term- 
"correct program" could relate to the internal correctness 
of a piece of code, i.e. to its syntactic correctness. For a 
reasonable grammer the question of syntactic correctness can 
be solved quite mechanically: every acceptable compiler does 
it all the time. On the other hand, if the syntactic 
correctness of a program cannot be resolved mechanically, we 
are dealing with a programming language too ambiguous for 
any semantic interpretation, with a text too vague to be 
considered meaningful. (A more puritan viev would be to 
state that syntactic unresolvability precludes semantic 
modelling and thus such texts are meaningless.) Since it is 
safe to assume that we are willing to restrict our 
considerations to programs that are guaranteed to be 
meaningful, i.e. to such programs that are guaranteed to 
have. a nontrivial semantic model, we assume that programs we 


are considering are guaranteed to be syntactically correct. 


As soon as we decide that we wish the term "correctness" to 
express more than just syntactic correctness, we must look 
for an external frame of reference. (Nothing suprising in 
it: in a scientific sense, correctness, just as 
truthfullness - in a slight departure from common usage — is 
always a dyadic relation that holds, or does not, between 
two entities rather than being a property enjoyed, or not. 
by an entity taken in isolation.) For a_ meaningful, 
purposful, useful program, the frame of reference that seems 
most natural for establishing the program's correctness is 
its specification, i.e., a statement of the program's 


purpose. 
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Thus we consider a program and a specification. For some 
such pairs we are entitled to state that program Pois 
COLTEE | with respect to the specification SS. The 
verifiaction of whether a particular pair (P,.S) entitles us 
to make this statement depends. of course. on a great many 
additional considerations. (Incididentally, L am afraid that 
some readers are beginning to suspect that I am overly 
pedantic, that I indulge in’ an academic nitpicking; let me 
hasten to assure them that me concern is very practical: it 
is precisely because I am interested in useful programs that 
I am rather particular about expressing my objectives quite 
clearly and opt for writing a watertight warranty that the 
program will indeed satisfy my goals as expressed by the 


specifications.) 


We leave aside, for the moment, the objections that one 
seldom is interested in actually verifying if an arbitrary 
program P is correct with respect to specification S, that 
our main interest is in producing programs that enjoy this 
property vis a vis given specification. After all, unless we 
have a better procedure, a thorough quality assurance test 


is a purchaser's best friend! 


Perhaps the simplest form a program specification can take 
is a pair of statements, IN and OUT, each of which can be 
either true or false, depending on the environment in which 
it is to be evaluated. (Some sentences, tautologies, are 


true (or false) regardless of an environment; if we fancy 


it, we may introduce the statement TRUE which - by 
definition - is true in every environment, and the statement 
FALSE - false in every environment, these two statements are 


suprisingly useful!) Using = an IN/OUT pair we express the 
following request: we want a program P such that if its 
execution starts in an environment. in which IN is true then 
after its execution is completed we shall get. an environment 


in which OUT will be true. This request can be written as a 
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formula: 
For example, with IN and OUT as before, and 


(IN) P (OUT) (x) P : 


in which P- is an unknown, or desired, program. Thus this 
formula may be considered as an equation that defines . 
we get the conjecture 
program P. 
(integers x,y are defined) 
For example 
pie, if x>-y =+> m:-x 


yY>rx ==) m:=y fi 


(integers x, y are defined) P (integers x,x,m are defined . . 
(integers x,y,m are defined and m = max(x,y)) 

and m = max(x,y)) 

There are two varieties of thus understood correctness: 
is a specification for a (small) program P that culls the , oo, 

partial and total. The distinction relates to the fact that 
maximum of two given integers. 

some programs are known to contain endless loops, or - what 

is more realistic - to contain instructions which initiated 
Now, how do we proceed to verify that a given program P is . . 

in. some environments may loop forever. Partial correctness 


correct with respect to its IN/OUT specification? There are . ; ; 
amounts to saying: it is guaranteed that provided the 


several ways of doing it, depending on _ the particular . . 
execution of P comes to anormal end the conjecture (x) 


fashion in which semantics of the rogramming language 
prog & Buag holds. Total correctness amounts to a = stronger: it is 


employed for coding P is formulated. If we are to proceed at ; 
guaranteed that the execution of program P will come to a 


all however the semantics of this language should be 
) ’ Ss guage normal end and that conjecture (x) holds. 


expressed in such a way as to permit calculations of the 


environment transformations effected by the execution of the . . . . 
The investigations into the extent of the notion of program 
language instructions. Knowing how the’ execution of each 
correctness led to many useful programming techniques. 
instruction transforms its inherited environment into the . ; 
Methods of composing programs in such a way that their 
environment for its successor, we can ascertain if the . ; 
. correctness with respect to given specifications would be 
execution of P, starting from its first executable . ; 
guaranteed by virtue of construction steps taken were 
instruction initiated in the environment satisfying IN, will ; ; 
developed and made quite practical. The key to the success 
lead, transformation by transformation, to an environment 
of these developments was the appreciation of the 
satisfying OUT. Thus we can establish the correctness of P ta: . . 
calculability of environment transformations effected by the 
with respect to IN/OUT by proving the conjecture that arises . . ; 
execution of programming language instructions with 
when the text of program P is substituted in (x). Note that . . oo, 
well-defined senantics. This in turn led to a considerable 
the ability to carry out this roof depends on the abilit . ; 
y y Pp P y effort in formulating calculable semantics of programming 
of a rigorous definition of the programming semantics. ; 
languages, and - in due course —- to certain preferences in 


programming languages themselves. 
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The intuitive approach to programming language design The length of formal manipulations involved is still quite 


(wouldn't it be nice if we had such and such feature in our impressive, but in this case the effort spent on "formal 
language) was replaced by a more somber attitude: let's have manipulations" should not be considered as an addition to 
in our language only such constructs which have calculable the cost of program development. If a programmer develops a 
semantics, and preferably select those whose definitions habit of formally deriving programs from specifications, 
make semantic calculations easy. then all his activities related to program construction, 

indeed, the whole problem-solving process is carried out by 
In recent years, many techniques based on _ calculable these formal manipulations. Starting with the necessary 
semantics and on the principle of provable program problem analysis and derivation of auxiliary facts, through 
correctness with respect to its specification emerged and structutal analysis, decomposition and = linguistic 
found practical applicaton. Even if the practiced version of interpretation (stepwise refinement), and ending with final 
a programming technique is not explicitly calculational expansion (coding) - all these steps, which one way or 
(structured programming, stepwise refinement, Jackson method another must be present in program derivation, are combined 
etc.), their origin is unmistakable and their soundness into a formal derivation of a program. Seen from this point 
depends on the firmly established mathematical theory of of view the length of the derivation is a measure of the 
program correctness. effort needed to properly construct the program. As usual, 


the derivation may be more or’ less detailed, some people 


It is often said that the formal methods of program learn to perform in their heads longer transformations than 
verification and/or program derivation from specifications others, but the fact remains: formal derivation of programs 
are applicible to small problems only, or less kindly is not any longer than an informal one. It is, however, more 
spoken, toy problems. Two justifications are put forward in explicit, provides a better documentation and is a whole lot 
support of this thesis. The first one points out that the less vulnerable to a chance mistake or oversight. In a 
volume of formal manipulations needed to verify a program is sense, it is a pity that the published examples of formal] 
usually an order of magnitude larger than the volume of the derivations of programs - for dydactic purposes - refer to 
program text itself, which makes this approach impractical very simple problems only: because it is so easy to derive 
for large problems. The second one questions’ the basic the specified programs in one's head, an explicit formal 
premise of the method - the availability of precise protocol of the derivation seems too long and, perhaps, 
specifications. Both objections are well-founded; the second unnecessary. 


one is however much more serious and will] be dealt with 
somewhat later, in a broader context. The relationship between a specification and a program is 


not a function: given a specification there may be a great 


As far as the length of the verification proofs is concerned many different programs that satisfy it, i.e. are correct 
we should in all fairness observe that the verification of with respect to this particular specification. If the 
an existing program against an existing specification is a specification is Loo vague, i.e. if it does not capture all 
relatively infrequent event. A much more realistic approach important requirements, a correctly constructed program may 
is to use the calculable semantics for deriving the program. turn out to be not quite satisfactory. This raises'a very 
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controversial] issue of the extent of programmers' 
responsibility: does it cover a everification of the 
specifications? And if so, what is the frame of reference to 
be used in such a verification? With this problem, however, 
we are leaving that part of software enginecring which could 
be conveniently called programming methodology, the only 


part in which solid progress over the last decade can be 


reported. 


Contrary to a popular belief, the completeness’ of 
specifications - at least the mathematical completeness - 
would not necessarily be an unconditional blessing. First of 
all, it would be very difficult to achieve, secondly, it. 
would almost invariable amount to overspecification in terms 


that matter for the ultimate use of the program. 


Deriving a program to meet a given specification, a 
programmer is free to use his judgement, rely on his 
expertise, draw upon available knowledge and recources, make 
decisions in all issues that are left unspecified. For 


example, a specification may read as follows: 
IN: Al,...,AN is a defined sequence of integers. 


OUT: (i) BIl,...,BN is a sequence of integers and 
(ii) B1,...,BN is a defined permutation of 
Al,...AN and 
(iii) i<=j ==> Bi =Bj for all 1<=i,jp=N 


This is, of course, a specification for a sorting program. 
The choice of the sorting algorithm is left unspecified, the 
programmer may explore this freedom as he wishes - provided 
the program he produces’ satisfies the given specification. 
If the specification was a bit "more complete" and asked, 
for instance, that the cost of the program execution should 


not exceed kNlogN, a large class of algorithms would be 
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excluded; similarly, if it) was specified that the programs 
should not. use more than 10% extra memory on top of the N 
cells needed for the vector A. Observe, however, that in 
order to express such additional constraints on the program, 
the specification must be formulated in a language much 
richer than that needed for the initial one: the extended 
specification must encompass notions quite alien to the 
problem of sorting. (Incidently, the IN/OUT style of 
specifications does not lend itself very naturally to such 
additional specifications, but this is a relatively minor 


point.) 


In aiming for completeness of specifications great care must. 


be excercised that their consistency be preserved. 


The inconsistency of specification is much more harmful than 
its incompleteness. An  incomlete specification can be 
satisfied by many different programs, the only danger being 
that. the one actually derived would not meet = some 
unspecified requirements (while being in full accord with 
the specified ones!) An inconsistent specification cannot be 
met. by any program! (In our’ example, it suffices to extend 
the given specification by the request that the cost of 
executing the program be less than kN, for fixed k and N, to 


make the thus extended specification inconsistent.) 


Thus a modicum of incompleteness of the specification is 
harmless ( and in = practice unavoidable), whereas’ the 


inconsistency must. be categorically avoided. 


The ability to produce correct programs given consistent 
specifications, the ablility gained through caclulable 
formalisation of semantics of programming languages, has 
caused a marked shift. of research interests away from issues 
towards the issues of 


of programming languages, 


specification. 
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There are several ways in which this relatively new research 
topic is likely to produce’ results important for practical 
work. (In some of these directions considerable progress has 
already been made, and practically significant results and 


techniques are available. ) 


The directions closest to the traditional programming 
activity is that of formalisation of program-objects 
specification (such as data types, modules, monitors etc.). 
In fact, the methods of specifying these objects are so 
closely related to programming techniques, that frequently 
they are considered Simply as parts of programming 
methodology. Yet, it is worthwile to observe that the same 
techniques may be applied to specification of objects not 
necessarily related to programs. 

Consider, for example, the abstract data type 
specifications. In the briefest possible exposition, one 
could say that an abstract data type is specified by two 


sets of formulae: 


(i) syntactic rules, 


(ii) semantic equations. 


The syntactic rules describe the morphology of objects of 
the type being defined and the syntax of specified 
operations acting on these objects; the semantic equations 
express - in calculable fashion - the properties of objects 
and operations. The publicised examples relate to well-known 
program objects (stacks, queues, tables, etc.) but the very 
same technique can be applied to specification of any 
objects that can be abstractly viewed as _ many-sorted 
algebras. In fact, since there is no fundamental reason why 
this technique could not be applied to, say, data base 


specification and since ( as we are repeatedly told) data 
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bases can be used to faithfully ( well, sufficiently 
faithfully) 


buisness data processing, I see no reason whatsoever why the 


represent almost anything of interest in 


abstract data type specification techniques could not be 
applied to specification of software, e.g., for management 
information systems. (Indeed, some experimental results in 
this spirit have been reported in research publications. ) 

Similarly, the techniques used for specifying active 
software components, such as modules, monitors, and classes, 
can probably be used for specification of simulation 
software. In fact, since most of the work in this direction 
is based on the original contributions of SIMULA 67 - a 
language initially intended for programming simulation 
computations - using these techniques for specification of 
simulation software would in a_ sense complete a full cycle 


of development, which is always intellectually pleasing! 


Several projects are currently under way trying to combine 


various specification techniques into specification 
languages, or more precisely, into software specification 


languages. 


The most important advantage of specification languages 
based on formal specification techniques would be _ the 
availibility of an extensive calculable apparatus enabling 
the verification of software produced according to the 
specifications expressed in such languages. Let me once more 
stress the importance of such an apparatus. Unless the 
notation of satisfaction is formalized, it cannot be made 
calculable. And unless we have a calculable means of 
establishing whether a piece of software satisfies the 
specification, we are on the very shaky ground of debugging, 
test-case verification etc., which never leads to foolproof 
assurances. Recall that it was the introduction of 


calculable semantics of programming languages’ that made 
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possible a satisfactory interpretation of the program 
correctness problem, and, aS a consequence, led _ to 


programming methods that guarantee the program correctness. 


Another - and in a way no less’ important - advantage of 
formalized software specification languages rests’ in the 
ease with wich they permit the construction of assorted 
aids, facilitating the process of programming by performing 
a host of clerical functions (cross-referencing, indexing 
etc.), by executing various checks (inconsistency of 
interfaces, use/define matches etc.) and - in some instances 
- by simulated "execution" of specified, but not yet fully 
programmed, software. Especially in large software projects 
such aids reduce the burden of ancilary functions’ on 
programmers and thus increase their productivity by allowing 
a less diluted concentration on main tasks. Again it should 
be stressed that the formalisation of the specification 
language (both of its syntax and semantics) is the crucial 
factor in determining how extensive a set of aids can be 


constructed. 


Another direction of research on’ specifications concerns 
operation on specifications, such as extending a 
specification by additional requirements and joining two 
specifications into one. Such operations closely correspond 
to situations frequently encountered in practice; in fact, 
as we shall see in a moment, manipulations’ with 
specifications are about the most important tool in software 
engineering. In order to attach meaning to results of 
formally defined operations on’ specifications, a suitable 
formal view of specifications had to be established. This 
waS accomplished by considering specifications as algebraic 
theories, in which case the theory of categories provided 
the necessary framework. Burstall's language CLEAR has been 
explicitly designed for describing specifications as 


theories and for programming operations on them. 
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Al] the so-far discussed research directions on 
specification issues implicitly assume that the 
specifications are the ultimate source of inspiration for 
software. This view is clearly inadequate for practical 
applications, where the utimate source of inspiration is a 
need felt by the customer, a need usually poorly articulated 
and nearly always expressed in terms far removed from 


program-oriented terminology. 


Theoretically, we could argue that the steps necessary to 
convert such a nebulously formulated need into a 
specification for a software (system) do not’ belong to 
software engineering. Personally, I do not subscribe to this 
view. First of all, if the pre-specification steps are 
excluded from the scope of software engineering we shall not 
have any real control over their quality, and there is very 
little sense in making an effort to produce high quality 
software hanging on low quality specifications. Secondly, it 
is in the link between the customer's needs’ and 
Specifications that the most troublesome aspects of software 
engineering have their roots (as we shall see in a moment). 
Thirdly, an interface between the pre-specification problem 
analysis and the specification must be established: if we 
admit that the former is quite informal and the latter - 


formal, the interface could be extremely akward. 


One way of extending the software engineering towards the 
analysis of customer's needs consists in providing 
semi-formal tools (such as, e.g. SofTech's SADT) to be 
applied to the analysis of customer's requests expressed in 
his language. The use of such tools imposes’ certain 
discipline on the formulation of the need, mostly syntactic 
and structural, thereby establishing syntactic relationships 
between various structural entities. Roughly speaking, on 


sucessful application of such various tools we get. a 
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counterpart of syntactic rules of algebraic specification, 
albeit sometimes expressed in a form much less convenient 
for subsequent manipulations (in the case of SADT we get a 
pictorial presentation of syntactic rules). The semantic 


equations are not so easy to obtain by semi-formal analysis. 


One can point out an analogy of a sort between the 
semi-formal requirements of analysis and flowcharting as a 
means of program design. It certainly is a step forward with 
respect to totally informal (unstructured) analysis, but 
without formalisation of corresponding semantic notions we 
are still left without means to verifiably establish the 
correctness of our proceedings. It should be observed that 
the commercial success of semi-formal techniques’ in 
customers' problem analysis provides an empirical proof of 
the practical recognition of advantages extending software 


engineering outside the specification/program bracket. 


An alternative approach to the analysis of customer's 
problems has’ been motivated by considerations of software 
evolution. It is a well-known fact that software systems in 
continuous use over extended periods of time evolve. The 
causes of evolution fall roughly into two categories: 


internal and external. 


Internal causes of software evolution include two major 


classes: 


- corrections 


- improvements. 


Corrections are such software changes that remove discovered 
errors, i.e. violations of the satisfaction relationship 
between an existing specification and an existing program. 


Theoretically, if the software is correct with respect to 
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its specification, no corrections are necessary. In 
practice, they do occur, just as errata are occaSionally 


necessary to texts of mathematical proofs. 


Improvements are such. software changes that leave the 
Satisfaction relationship between the existing specification 
and program intact and exploit the freedom left by the 
Specification in order to bring about advantages that cannot 
be described in the linguistic system employed for the 
specification. A typical improvement is the replacement of 


an algorithm be a less complex one or by a "faster" one. 


External causes of software evolution may be also classified 


into two groups: 


- related to the change of programming environment, 


~ related to the change of specification. 


A change of programming environment occurs e.g. when the 
hardware system is extended by a new component or a new 
hardware facility is added that extends the repertiore of 
programming means of expression. A more radical change of 
programming environment is caused by replacement of 
hardware, in which case (all or some) programming means of 
expression lose their hardware interpretation. An extreme 
case of programming environment change is a switch over from 
one programming language to another, or from one operating 
System to another, or from one manufacturer's hardware to 


another's. It should be observed that: 


(i) a change in programming enviromnent does not 
necessarily involve a change in software (e.g. we 
may ignore an added hardware facility), in which 
case the situation is roughly similiar to that of 


internal improvements, 
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(ii) if the change of programming environment is modification activities are constantly challenged as 


forcing a change in software, such change is to wasteful and poorly managed. It would be’ much better to 
be effected under the invariance of speak of specification maintenance in the presence of 
specification, excepting the somewhat ludicrous internal causes of software evolution and in the case of a 
cases where the specification contains the change in programming environment, and to call a spade a 
explicit request that products of ABC company are spade in case of specification changes. 


to be used. 
Two symmetrical errors, commonly committed, contribute to 


Thus we have isolated the only kind of software change that the bad reputation of software evolution: 
is caused by an aS it were spontaneous’ change in 
specifications. Why should a specification change at all? (i) forgetting to maintain the specification when 
Well, there are several reagons: software is changed for internal reasons, 
(i) the original specification poorly captured the (ii) specifying software changes without making 
customer's needs, certain that the resulting specification is 
consistent. 


(ii) the customer changes his mind, 
An often encountered variation of the second error constists 


(iii) the use of the system changed the customer's in making software changes when the customer's needs have 
environment in such a way that his needs have changed, without bothering to modify the specification at 
materially changed. all. This practice is supported by the befief that "software 

models the application", hence if the application changes, 
All, who ever participated in a _ significant software the software should change accordingly. In fact, the 
developent project, are well familiar with at least one of software is related to an application through the 
these, more often - with all. specifiction, and if the verb "to model" is to be used in 

its technical sense, then software models its specification. 
In the professional jargon, the activity of changing the Thus if we want to stabilize the software evolution, we must 
software is circumstantially called “software maintenance". jealously maintain the specification-software relationship, 
It is a particularly absurd choice of terminology to speak and allow such software changes only which either werifiably 
of software maintenance when we mean_ software changes; preserve this relationship under invariance of the 
unfortunately it is being done all the time! The use of this specification, or re-establish this relationship when the 
misnomer is also exceptionally harmful from the specification has been modified in a consistent way. 
psychological point of view: it is subconsciously expected 
that any maintenance should be relatively inexpensive (in The relationship between the specification and software 
comparision with the original investment). Software being thus promoted to the role of main’ concern of the 
"maintenance" being anything but inexpensive, the software programmer, how do we envisage the pragmatically important 
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link between the customer's needs and the - necessarily In addition to the methodological advantages, the proposed 


formal - specification? In order to achieve a pleasing arrangement may be used as a framework in which stable 


Symmetry and a simple, conceptually unifying treatment of evolution of software may be clearly monitored, and thus at 


both considered environments (the program environment in least some calamities may be prevented. Indeed, assume that 


which a program models a specification, and the application the customer feels a need to modify the software. This need 


environment) I suggest that the particular application be must be expressible as a change in the application model (no 


considered a model of the specification in the application other means of articulation is admitted, or to put it 


e > + ' 
domain. In this way, formally at least, the relationship bluntly: all other means of articulation of the customer's 


between the particular application and the specification is wishes are simply dangerous and should be disregarded). Thus 


exactly of the same kind as the relationship between a modification of the application model is considered as the 


specification and software. only possible source of the initiative for software change. 


We may safely assume that such modification violates the 


The major advantages of such an arrangement come from the existing relationship between the specification and the 


obligation to prove that the application satisfies the application model. (Even if the specification/application 


specification. This means that the application must be relationship is not broken there may be a valid reason to 


presented so precisely that such a proof would be possible. change the specification - it just has been demonstrated 


At the same time, it does not mean that the application must that it is too insensitive to application domain 


be described in programming terms. The choice of the modifications! ) 


language used for application description is left entirely 


to the application experts, the only requirements being that The ensuing change of the specification must be effected in 


it has a calculable semantics, just as the programming a formal system in which the specification is written and 


language has one. the modified specification must be checked for consistency. 


At this stage some changes may be rejected, others may cause 


Just as there may be many programs satisfying any given us to think very seriously if it is really worthwile to 


specification, many applications may fit a given introduce them (if the resulting modifications of the 


specification. The freedom left by the specification in the specification are massive, the work involved in changing the 


application domain is now a measure of how precisely the software may be expected to be similiarly extensive. ) 


specification captures the customer's needs. If, with a 


given specification, one gevs too unrestricted application When the specification is changed and thus the satisfaction 


models the specification has to be tightned. relationship between the specifications and the application 


domain model is re-established , a crucial decision must be 


Naturally, in the temporal sequence of events, the taken: to modify the software (because it does not model the 


specification hardly precedes the application model. In specification any more) or to construct a new software. This 


practice it will be somehow abstracted from a description of unavoidable decision is in the considered arrangement 


the application, but the abstraction process (present in all somewhat less arbitrary than in other set-ups because it is 


system design methods) is now verifiable. prededed by a full-scale formal modification process 
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performed on the specification. 


Most importantly, if the specification changes are expected, 
the construction of software may be subject to certain 
rigours, making subsequent specification-directed 
modifications of software easier. (Modularity, seperation of 
concerns, splitting a specification into covering 
"Subspecifications".) A particularly promising technique 
consists in anticipating (at least some) changes in 
specification, cataloging them and providing - a priori - 
algorithms for changing the software so as to incorporate 


any of the catalogues specification changes. 
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INTRODUCTION 


The question of whether or not a computer system is being effectively 
utilized is often difficult, if not impossible, to answer. Equally 
difficult can be the identification of a bottleneck when the performance 
of a system is less than expected. These difficulties typically arise 
due to a lack of information on which to base a judgement or decision. 
Even in those situations where information is available, it is often the 
case that information is incomplete, or possibly inaccurate or 
misleading, thus forcing the analyst to make a “best guess" as to the 
true situation. When detailed and complete information is available, it 
is frequently difficult to separate the useful information from the vast 
amount of data provided. In this paper we describe an interactive 
software product designed specifically to aid in the analysis of HP 3000 
computer system performance, and which addresses the problems just 


described. 


This product, the HP On-line Performance Tool (OPT/3000), is Hewlett- 
Packard's first performance measurement software product, and can be 
used to identify performance problems or bottlenecks, to characterize 
the workload on an HP 3000, to collect information required for capacity 
planning activities, to analyze system table configurations, and in some 
cases, to tune the performance of individual applications. OPT/3000 
provides information in 23 separate interactive displays in the 
following areas: CPU utilization and memory management activity, memory 


usage, I/O traffic, program and process activity, and system table 
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usage. Although each display is designed to be quickly and easily 
understood, the assumption is made that the user has been trained on the 
internal operation of MPE IV, the newest version of the HP 3000 
Multiprogramming Executive operating system. OPT/3000 is designed to 
operate in conjunction with MPE IV and can be used on any HP 3000 Series 


II, Series III, Series 30, Series 33, or Series 4h. 


This paper presents an overview of the HP On-Line Performance Tool, and 
discusses some intended applications of OPT/3000. The information 
reported by OPT/3000 is also reviewed in-depth, as well as the 


techniques used to obtain the information. 


OVERVIEW OF OPT/3000 


The HP On-line Performance Tool is a software product that provides 
performance related information in an interactive environment. As 
mentioned earlier, OPT/3000 can generate 23 different displays 
containing performance related information, in addition to seven menu 
displays. These displays are grouped into six categories, called 
display contexts, each of which is associated with a different type of 
system resource. The six contexts are: Memory, CPU/Memory Management, 
1/0, Process, System Tables, and Global (a little bit of everything). 
Within each context, displays are available at successively greater 
levels of detail. This structure allows the user to progress from 


summary level information to more detailed information as the situation 
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requires. In many cases, the summary level information is sufficient. 


Once a display has been generated, it is automatically updated at 
periodic intervals, with the length of the time interval under control 
of the user. A display can also be updated upon demand, simply by 
entering a carriage return. All commands within OPT/3000 consist of a 
single ASCII character, and a different set of commands are available in 
each display context. Certain global commands are available in all 
contexts. In addition, the pound sign character (#) is used as an 
escape character to access a set of control operation commands. These 
commands perform such operations as changing the current display context 
and suspending the updating of the current display. With this simple 
user interface, the generation of a different display within the current 
context is accomplished via a single keystroke, and the generation of a 
new display within a different context with a minimum of three 
keystrokes. Menu displays are available within each context, and list 


the commands available within that context. 


An extensive on-line help facility is also available as an integral part 
of OPT/3000. With this facility, documentation explaining any command 
or display can be quickly displayed. In many cases, interpretation 
guidelines are also provided to aid in the identification of performance 


problems. 


OPT/3000 utilizes the features of the HP 264x series of terminals to 


generate displays with a graphical format, where practical. The 
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terminal features used include the four available video enhancements 
(blinking, inverse video, underlining, half-bright), the line drawing 
character set, and the cursor addressing capabilities. OPpT/3000 
automatically checks to verify that an appropriate terminal is being 


used, and warns the user if an incompatible terminal is in use. 


A hard copy of any display can be generated on the line printer (device 
class LP) with a single keystroke. The hard copy displays are similar 
in layout to the interactive displays, but some reformatting is 
necessary to convey the same information, due to the lack of video 


enhancements on a line printer (e.g. paper cannot blink). 


Although the HP On-line Performance Tool is primarily designed for 
interactive use, it can be executed in batch mode to collect summary 
information about system activity. These summary reports can be used to 
provide data for capacity planning activities, and can be generated 
interactively as well. Once activated, the summary reports are 


generated independent of the interactively generated displays. 


There is no limit on the number of copies of OPT/3000 which can be 
executing simultaneously. OPT/3000 obtains much of its information via 
a new internal measurement interface facility incorporated within MPE 
IV. This facility maintains a set of measurement counters accessible by 
multiple users. Additional information concerning the measurement 
interface, and the techniques used by OPT/3000 to collect information, 


will be discussed in a subsequent section. 
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APPLICATIONS OF OPT/3000 


There are several anticipated uses for the HP On-line Performance Tool. 
Among these uses are the identification of performance problems and 
bottlenecks, the analysis of system table configurations, 
characterization of the system workload, capacity planning, and 
performance tuning of applications. Each of these activities utilizes 
some or all of the capabilities of OPT/3000. We will now briefly 
discuss each of these application areas before describing in some detail 


the information provided by OPT/3000. 


The ability to quickly move between displays and the variety of 
information available through OPT/3000 facilitates its use in 
identifying performance problems and bottlenecks. In particular, it is 
expected that a system clearly bottlenecked by CPU, memory, or I/0 will 
be quickly identified. OPT/3000 can also be used to determine if disc 
accesses are unbalanced between multiple drives. Poorly behaved 
application programs can also be identified, in terms of programs which 
use excessive numbers of files and extra data segments and those which 


waste stack space. 


A second application area is that of system table configuration 
analysis. Inappropriately configured system tables can degrade system 
performance, either by wasting memory if the tables are unnecessarily 
large, or by causing processes to delay while waiting for an entry in a 


table that is-configured too small. In the latter case, system failures 
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may also result if the table size is exceeded. OPT/3000 allows the user 
to quickly identify those tables which are not properly configured, and 


to determine (through utilization statistics) a more appropriate value. 


The characteristics of the workload on an HP 3000 can be determined 
using OPT/3000. The names of all active or allocated programs on the 
system can be easily determined, as well as the users of each program. 
The CPU usage, disc I/O rate, and memory usage characteristics of an 
individual application can be determined if the application is running 


stand-alone on the systen. 


The summary reports which can be generated by OPT/3000 in either batch 
or interactive mode can be used to provide data for capacity planning 
activities. These reports indicate the CPU usage of the system, memory 
Management activity, and the I/O traffic on individual discs, line 
printers, and magnetic tapes. The information used to generate the 
summary reports can also be logged to an OPT/3000 log file (disc or 
tape), which could be processed to provide input for generating plots. 
In this manner, OPT/3000 can gather trending information that can be 
used to determine when additional peripherals or systems are needed, or 


to detect changes in the day-to-day processing load. 


Although OPT/3000 is oriented towards the measurement and analysis of 
the system as a whole, it can be of some value when tuning the 
performance of individual applications. In particular, OPT/3000 can 


provide information relating to an application's usage of files and 
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extra data segments, plus detailed information about the application's 


use of its stack. CPU usage information is also available. 


INFORMATION PROVIDED BY OPT/3000 


As mentioned earlier, the HP On-line Performance Tool provides 
information in six different display contexts: global, memory, 
CPU/memory management, I/0, process, and system tables. In this section 
we describe the types of information available in each context. In 
general, the information provided by OPT/3000 can be divided into two 
basic classes. The first class of information shows the state of some 
aspect of the system at the moment the display update is generated. 
Examples of this class of information include the current contents of 
main memory and the current list of active programs. The second class 
of information summarizes activity within the system during some 
interval. CPU utilization and disc I/O rates are examples of this 
second class of information. In most cases, this summary class 
information is reported for two types of intervals: the interval between 
the previous display update and the current display update, and the 
interval encompassing all update intervals since the start of OPT/3000 
execution. These two intervals are herein referred to as the current 
interval and the overall interval, respectively. The user can clear all 
totals associated with the overall interval at any time in order to 
start a new overall interval. We will now discuss the information 


available in each of the display contexts. 
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Global Context 

The global context is automatically entered upon execution of OPT/3000, 
and it provides summary level information concerning CPU usage, memory 
utilization, disc I/O rates, and process activity. The generation of 
summary reports is also controlled from the global context. The two 
displays in the global context can be used to quickly determine 
potential problem areas (e.g. memory bottleneck), and then more detailed 
displays in the other contexts used to isolate and verify the problem at 
hand. The global context can also be used to monitor general system 
activity, in order to detect fluctuations in resource usage. The CPU 
and disc I/O information summarizes the activity for both the current 
and overall intervals, whereas the memory and process information 


describes the situation at the time of the update. 


badoiy Content 

The memory context consists of eight displays, and provides information 
related to the usage of main memory and segment sizes. Three of the 
displays provide information related to the current contents of memory 
and the remaining displays consist of histograms depicting distributions 
of segment sizes or free areas in memory. The highest level display 
concerned with the contents of memory allows the user to determine the 
current percentage of memory containing code segments, stacks, and extra 
data segments. Additionally, the user can determine the type of code 
and data segments in memory. For example, the user can determine the 
percentage of the extra data segment memory usage that is due to 


IMAGE/3000, KSAM/3000, the file system, or system tables. Likewise, 
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code segment memory usage is separated into segments originating from 


program files, and those from segmented libraries. 


The user is also able to generate an image of the current contents of 
main memory, either for all of memory or for a single bank (64K words). 
This image indicates the type of each segment (e.g. file system data 
segment, stack, program file code segment), the approximate size of the 
segment (in either 1K or 64 word increments), and other miscellaneous 
information about the segment (e.g. is it locked or frozen?, is it an 
overlay candidate?). These images are generated by utilizing the 
display enhancement capabilities of the HP 264x series of terminals, and 
consist of a sequence of alternating white and gray rectangles 
(generated using inverse video and half-bright). Each rectangle 


represents an individual segment. 


The histogram displays depict the distribution of segment sizes, in 
either 1K or 512-word increments. The highest level display depicts 
separate distributions for code, stack, and extra data segments. The 
remaining four histogram displays generate higher resolution histograms 
for each of the above three segment types, plus one for free areas in 
memory. The histograms are generated using the line drawing character 


set of the terminal, so as to provide maximum resolution. 


CPU/Memory Manager Context 
The CPU/memory manager context includes three displays with information 


related to CPU usage and memory management activity. The highest level 
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display provides information about both CPU and memory management 
activity, while the remaining two displays provide more detailed 
information about each of these areas. All information provided in this 
context is of the interval summary class, with information for both the 


current and overall intervals. 


The CPU information provided allows the user to determine the percentage 
of time the CPU is in various states, as well as the rate at which 
processes are being allowed to execute in the CPU. The reported CPU 
states include CPU busy executing processes, CPU time for memory 
management, CPU time on background memory "garbage collection", CPU on 
overhead processing (e.g. handling interrupts, dispatcher time), CPU 
waiting for user disc I/O to complete, CPU waiting for memory management 
I/O to complete, and CPU idle. Information for process launches and 
process preemptions is reported as the number of occurrences of the 
event per second (i.e. as a rate). Reported rates include the current 
interval, the overall interval, and the maximum rate observed in a 
single interval since the start of the overall interval. These three 
rates are depicted with a one-line bar on the terminal screen, utilizing 
inverse video and half-bright inverse video to indicate the current and 
maximum rates, plus an asterisk to denote the mean rate over all 


intervals. 
Event rate information is also reported for memory management activity 
in this context. The events reported include memory allocation, memory 


management disc I/O write, memory management disc I/O read, reiease code 
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segment from memory, and release data segment from memory. Information 
is also available concerning how the memory manager satisfies requests 
for absent segments. When a segment absence fault occurs in MPE IV, the 
algorithm used by the memory management routines can terminate with one 
of five possible outcomes, ranging from recovering the segment from the 
list of overlay candidates to temporarily postponing the request to 
avoid thrashing. OPT/3000 shows the pores of memory allocation 
attempts terminating with each of the five outcomes. These percentages 
are shown for both the current and overall intervals, utilizing a bar 


with alternating white and gray areas. 


I/O Context 

The I/O context provides four displays regarding I/O completion rates 
for discs, line printers, and magnetic tapes. The highest level display 
indicates the I/0 completion rate per second for each type of device, 
for both the current and overall intervals. The remaining three 
displays provide more detailed information about individual devices 
within each device category. These displays indicate the completion 


rate for three types of I/O operations (read, write, and control) on 


each individual device. This information can be used to determine if 


the I/O traffic is balanced between the devices on the system, or to 


identify times of peak activity. 
Process Context 
The process context includes four displays with information concerning 


process and program activity on the system at the time the display is 
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updated. The highest level display provides information about all 
active or allocated programs. This information includes the fully- 
qualified program file name, the size of the program file in words, the 
number of segments in the ieee the number of current users of the 


program, and limited working set information. 


Once the above display has been generated, a second level display can be 
used to determine more detailed information about each process sharing a 
program file (or for system processes or command interpreter processes). 
The more detailed information includes the user name and account of the 
user, the process number (PIN), the size of the process stack in words, 
the CPU time used by the process, the number of open files and extra 


data segments, and the job/session number. 


Additional information about a specific process can then be obtained by 
generating a third level display. This display contains all of the 
information present in the second level display, plus more detailed 
information about how the process is utilizing its svack space (e.g. the 
size of the DL area, size of the global data area). Also included are 
the names of all open files, a list of son processes, and a list of 


explicitly obtained extra data segments and their sizes. 
Some of the information reported in the second and third level displays 
could be used to circumvent the security aspects of MPE. For this 


reason, these two displays cannot be generated by all users of OPT/3000. 


The security provisions within OPT/3000 allow a user with either system 


13 


Rl 13 


manager (SM) or operator (OP) capability to generate these two displays 
for any program file. Any other user can only generate the displays for 
a program file if they are the creator of the file, or are the account ~ 


manager for the account in which the program file resides. 


The remaining display in the process context provides information about 
the number of processes in various states. For example, the total 
number of processes waiting for blocked I/O, number of processes waiting 
for RINs, and the number of processes in the dispatch queue are 
reported. This information indicates the state at the time the display 


is updated, and no averages or totals over time are reported. 


System Tables Context 

The system tables context contains two displays indicating the current 
and maximum utilization of configurable system tables. One display 
provides only the current and maximum utilizations in a graphical 
format, using inverse video and half-bright inverse video bars. For 
almost all tables reported, the maximums are for the time since the last 
system warmstart. For the remaining tables, the maximum is that 
observed by OPT/3000. The second display provides more detailed 
information in a tabular format. This detailed information includes the 
configured number of entries, entry size, and maximum utilization 
observed by OPT/3000, as well as the current and maximum table 


utilizations. 
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MEASUREMENT TECHNIQUES 


The HP On-line Performance Tool obtains the information used to generate 
its displays from two basic sources. The first source is the new 
internal measurement interface facility within MPE IV, and the second is 
internal MPE data structures and tables. The measurement interface 
provides all information related to CPU usage, memory management 
activity, and I/O traffic. All other information reported by OPT/3000 


is obtained by examining internal MPE tables and data structures. 


The measurement interface facility in MPE IV provides OPT/3000 with a 
formal mechanism for accessing instrumentation within MPE IV. When the 
facility is enabled by OPT/3000, the measurement interface obtains an 
extra data segment to be used as a set of counters. This segment is 
then locked and frozen in memory and its location stored in a global 
cell. As events occur, the appropriate counters within the extra data 
segment are incremented by code within MPE IV, and accessed in a 
consistent manner by OPT/3000. The CPU state time information is 
maintained in a similar fashion. OPT/3000 determines the activity 
during an interval by comparing the current sample to the previous 
sample, and computing the change in each counter. A count of the number 
of processes that have activated the interface is maintained by MPE IV. 
When the count falls to zero, the extra data segment is released and the 
instrumentation disabled. This mechanism allows multiple copies of 
OPT/3000 to use the same shared instrumentation. As MPE continues to 


evolve, both the measurement interface facility and OPT/3000 will be 
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modified to reflect any changes within MPE. 


The overhead within MPE for maintaining the counters has been determined 
to be approximately 0.3 to 0.8 percent of available CPU time, depending 
upon the amount of activity within the systen. OPT/3000 can collect 
data from the extra data segment, and update all of its internal totals 
with the change in each counter in approximately 40 milliseconds. As 
can be seen from this data, the measurement interface facility provides 


a very low overhead method for obtaining performance information. 


All other information reported by OPT/3000 must be obtained by examining 
internal MPE data structures and tables. The information concerned with 
the current contents of main memory is obtained by scanning all of 
memory, examining each region and sub-region header (these are similar 
to the memory links in MPE III). The segment size histograms are 
produced by processing the segment tables. The information concerning 
program files and processes is obtained by examining the loader segment 
table directory, process control block table, and the process control 
block extension area in the stack of a process. System table 
utilization information is partially obtained by examining information 


maintained in the header portion of each table. 


The overhead required to gather any of the information just mentioned 
varies depending upon the system configuration. In general, the CPU 
time required to collect the necessary information and update any 


display ranges from 300 to 800 milliseconds, depending upon the display. 
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This normally translates into a total CPU overhead for OPT/3000 ranging 
from 1 to 3 percent of available CPU time, depending upon the displays 
generated and the frequency of display updates. An update interval of 
15 seconds is the default used, and results in overhead in the 1 to 2 


percent range. 


SUMMARY 


The HP On-line Performance Tool is part of Hewlett-Packard's integrated 
approach towards offering HP 3000 users alternatives in performance 
measurement analysis. In addition to OPT/3000, the first HP 3000 
software performance measurement product, a new System Performance 
Evaluation package and a new MPE Internals and System Performance 


Analysis course are being offered for HP 3000 users. 


The recently introduced HP 3000 System Performance Evaluation Consulting 
package offers an alternative to OPT/3000 for HP 3000 users who want 
system performance analysis conducted by HP Performance Specialists. 
These Specialists have in-depth training on the internals of MPE and on 
the performance characteristics of the HP 3000. They also have a number 
of HP-supplied software tools at their disposal, such as OPT/3000, 
IOSTAT, and the MPE IV Data Collection Program (MPEDCP), for collecting 


and analyzing performance measurement information on the HP 3000. 
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A new MPE Internals and System Performance Analysis training class is 
being offered in conjunction with the HP On-line Performance Tool. The 
first part of the course discusses the areas of MPE IV that are 
necessary for understanding the performance measurement information 
presented in OPT/3000, in particular, the new MPE IV memory manager, the 
dispatcher, scheduler and I/O areas in MPE IV, and the process 
structures. The second part of the course reviews the inter- 
relationships of the performance measurement variables discussed in the 
first part, and presents operational guidelines for OPT/3000. In 
addition, case study workshops will be used to share HP Performance 


Specialist techniques and experiences with class participants. 
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ORGANIZATION STRUCTURE OF THE CITY OF BERGEN 


Bergen, Norway's second largest city, is situated on Norway's West Coast 
about 500 km north west of Oslo. Once a Hanseatic city, and the largest 
Nordic city in 1600, Bergen now has a population of 210.000, and covers 
an area of 465 Te The city administration's number of full time 


employee equivalents is 10.000. The total 1981 budget is $ 400 mill. 


The administration's structure is very much like the divisionalization 
we often see in industrial corporations with an equal number of 
employees, with one staff division, The City Manager Division. Within 
this division, the EDP department is located. In addition there are 


some 10 functional divisions. 


To get a clear picture of the various EDP activities within the govern- 
ment, one has to make observations from different viewpoints. The 
systems have been initiated out of different needs, they are built and 
are working differently, and the administration's influence on the way 
the systems are developed varies from practically none to complete 


control. 


After the assimilation of some of the neighbouring societies in 1972, 


the main objectives of the EDP department can be summed up as follows: 


1. Consolidation of the joining (as of 1972) societies operating 


systems. 


2. Initiating and implementation of a number of comprehensive systems 
on a large IBM mainframe, owned jointly by local adminstrations and 


private enterprise in the region (= KDV). 


3. Setting up local, decentralized processing services, with data entry 
and information systems, partly for distributed interaction with 
exisiting centralized systems, but also for establishing, none-main- 


frame-dependant local solutions. 


R3 3 


"THE HAPPY TRANSITION 
Page 3. 


The development has been done in cooperation with the user divisions, 


and project groups have often been established for the various tasks. 


The city decided in 1972 against setting up an internal data processing 
centre with the resulting centralized development and processing con- 
cept. For control, planning and approval of the EDP activities a 
professional organ was established located in the City Manager's staff. 
At this point, a committee named by and among the politicians took of- 
fice. (The EDP committee.) Their mandate will be discussed later, 


after a look on how the consider 
INFORMATION TECHNOLOGY VS. ORGANIZATION THEORY. 


First, it is recognized that in relation to the development of data 


processing these two concepts must have a uniform and harmonic plat- 


form. It is commonly accepted that the information technology has great. 


influence on employment and the working environment, as well as areas of 
responsibility and distribution of competance, but also on the quality 
and rapidness with which tasks are completed. The technology also 
defines information accessability and availability in support of plan- 
ning and managing the society's development. Traditional organization 
theory points out a relation between the subsystems of technology, admi- 
nistration and the social subsystem, where the technological system is 
represented by machines and in this case also software, - the social 
subsystem by interhuman relations and structured, as well as unstruc- 
tured, ways of contact and communication. In the administrative subsys- 
tem we will find guidelines, policies, structures, plans and hierarchi- 
cal command lines. In the same way as with traditional technology, the 
information technology will impact on the administrative and social 
subsystems, especially when applied for rationalization purposes. These 
unreflected impacts are often felt negatively. If, on the other hand, 
the information technology is used purposely to influence and prepare 
the organization to cope with new tasks, and to solve old tasks in a 
different and more effective way to produce detail and new management 


information, this impact changes radically. 
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The effects appear in different ways, and often several at the same 
time. One obviously and very little desired effect is e.g. that 
know-how of certain (routine) jobs is drained out of the social system 
and instead put into the information technology as "axioms" e.g. burnt 
into ROMs. This will gradually transfer employees into "operators", 
resulting in loss of insight. A too technological information exchange 
is also a risk of making people lose their feeling of belonging in a 
social subsystem. Reallocation of competance and information through 
incompetent use of technology will gradually and undeliberately restruc- 
ture, and in the worst case, b.ake down the administrative subsystem, 


whether the effect is extreme centralization or decentralization. 


These phenomenons are some of the main reasons for the strong involve- 
ment we see throughout the world when EDP issues are discussed. They 
are also fundamental for the decision to have a co-ordinated development 
of the organization structure, people and data processing, and what is 
more important, the city must always master and control the information 


technology and the applied methods. 


THE EDP MASTER PLAN. 


The political controlling authority was when this situation was recogni- 
zed transferred from the EDP committee to Administration Committee as a 
consequence of the increasing importance of technology. An excerpt of 
it's mandate tells that: 


"The committee will have general guidelines approved for the use of EDP 
in the city administration, anc within these consider long range plans 
for the city's EDP development. These plans shall be designed also with 
regard to their social impacts within the city. The committee will 
influence federal and other public plans to reflect the needs of the 


city". 


The EDP master plan must, because of the strong relationship between 
organization development, personnel development and data processing, be 


integrated in the city overall long range planning. The master plan is 


the strategic plan for the EDP development the next 5 to 10 years. 
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It defines long range objectives, general guidelines to reach the obdjec- 
tives, and the span in regulation and the restructuring of activities. 
The resource plan will explain what resources are available or needed, 
in terms of personnel, technology, capital and know-how to reach the 
objectives. A tactical plan will state short term aims, with action 
plans, budgets and definition of resource available. This planning 
pattern has so far bee prevailing in the city's overall planning proce- 


dures, and has also been true for the EDP sector. 


The EDP master plan is the strategic platform for the long range activi- 
ties, as well as for the single projects. The Master plan is therefore 
considered by the Administration Committee (the politicians), and is 
approved as a directive for further development prior to the planning on 


the division and department level. 
SYSTEMS METHODOLOGY IN THE 60IES AND 7OIES 


Two types of systems have been prevailing: sectorial purpose system and 
function oriented systems. The sectorial systems have been serving the 
tax sector, the social security sector, the public and private property 
(real estate) sector, whilst the functional systems have been applied 
across division borders for applications as payroll, accounting and 


accounts payables and receivables. 


The systems were designed as self-contained systems within the single 
finctions, comprising data entry, transport/transmission to the central 
mainframe, storing, processing and result presentation. The functional 
systems have had the design objective to provide adequate solutions for 
the smallest as well as the larges public adminstration unit. Mostly 
these systems were developed by resources outside the city government 
administration. Often large project organization were employed to deve- 
lop and design the systems, and to make it possible for most of the 
involved parties to be heard. Typically, these projects were establi- 
shed and completed as inter city government co-operation. The size of 
the systems and their complexity, has resulted in an increasing staff of 
specialists within the differen system areas, but outside the city's 


administration. These systems are highly vulnerable, as operation 
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experience shows that their maintainability is person dependant. This 
city co op organization of system development have influenced the cost 
of development and operation, and competance has been drained out of the 


executing divisions into the system development organizations. 


This approach in system development in the 60ies and 7Oies has had the 
side effects of information centralization and reduced availability and 
accessability for the users, centralized competance, development and 
maintenance with reduced user influence possiblities. Local administra- 
tions are as a consequnce driven by conditions established in the EDP 


systems. 


The system development trends of the 60ies and 7Oies, have cemented the 


sectorial and central way federal and city governments manage. 
THE COMPLEXITY VS. COST ASPECT. 


Profesionally, it is recognized that the more complexity you introduce 
into a system to make it all-comprising, the higher the cost of develop- 
ment and operation will be. If we consider the cost aspect related to 
the completeness of a system, the cost will increase as a constant 
function until you have an approx. 80% coverage, while it'will take an 
exponential function to cover the last 20%. In other words, the 80-20 
rule is applicable, you do 80% of a project for 20% of the total cost. 
There was and still is a lot of room for productivity tools and action 


to improve this picture. 


These large systems also have certain needs to exchange data, and infor- 
mation integration between systems that one by one is complex, is not 
made easier by different software, software technology inherant in each 
system and the time factor for development. The systems are expensive 
to develop and operate, and it is necessary to have several users to 
make the cost of operation economically acceptable. This service bureau 
syndrome has gradually defined the cities' adminstrations as necessary 
for the continued growth of the IBM 3033 site mentioned earlier. Conse- 


quently, attempts to localize data processing on minis amd micros are 


often considered as threats to the large centralized 
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facility, and are therefore obstructed in different ways. 


The systems of the 60ies were mainly of the periodic batch type. File 
information was transferred from the classic ledger cards to magnetic 
representation. It was necessary to make frequent printouts of file 
information to keep an adequate level of information. The terminal 
solutions of the 7O0ies made on-line inquirires on passive registers 
possible. This change in information accessing made other organizing 
and retrieval methods necessary, involving higher cost of operations for 
the periodic systems. It also involved enhancements of the central 


computer. 


These complex common city government systems produced a staff of 
"experts", often located outside the local administrations and with 
little feeling for the administration's real needs. The situation can 
be labelled as "Systems by the experts and for the experts". We often 
find the user left with complex, technically oriented manuals, without 
true insight in how the system functions. The expected gain in produc- 
tivity and rationalization was not realized, and we see the users as 
suppliers of data (as contrary to information) and receivers of 
results. The user influence of their working environment is reduced, 


and in many cases the stress factors are increasing. 


Another aspect of these large systems is the fact that the register 
information is organized and primarily has the objective to satisfy 
sectors within the different divisions of the administration. It is 
necessary, however, for effective administration to have access to more 
data than defined for each sectorial system. Therefore, we see many 


manually driven support systems connected to the large, complex systems. 


As these effects of the centralized systems were getting more apparaent, 
it was now recognized that in order to stop the unfavourable development 
of cost, and to stop the drain of competance out of the administration, 
these large systems should be frozen, and the competence must be reesta- 
blished within the function units of the administration. Further, the 
units must build up their own EDP know how, enabling them to cope with 


their own problems. 
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LOCAL TECHNOLOGY. 


In the mid 70ies the situation described was getting increasingly 
obvious within the city. Distributed data processing seemed to be a 
solution, as it was necessary to continue using most of the large sys- 
tems for some years. It was made a policy to avoid participation in new 


inter city projects based on large mainframes. 


The first HP-3000 was installed at the City Manager's Division in mid 
1977. Successively, local computers were installed at the City trea- 
surer, the City Transport Authority and at the City Electrical Utility. 


The equipment covers functions within these main application areas: 


- Data entry and local storage 

- Local processing of local and remotely located information 
(other HP-3000 x IBM) 

- Data presentation (line printer, VDU and graphics) 

- Statistical analysis and presentation 

- System illustration models 

-  Programming/System Development 

- Data preparation 

- Data communication : 

- Education and training 


- Integrated text processing. 


The HP-3000s are linked horizontally to each other, using HP-DSN. 
Theoretically, any terminal user have access to all resources in the 
network, also including several connections to the IBM mainframe. In 


this concept all HP-3000 members in the network are equal. 
Relatively demanding tasks are asigned to the HP-3000, such as 


- setting up local, terminal based data entry and inquiry systems, 
working against the large (batch) periodically run inter city 
systems, and validation and transportation of data to and from 


these systems. 
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- establishing local interactive information systems and inter- 
action with local micros, data network, terminal administration, 
data reduction and aggregation, together with statistical 


analysis. 


A PHILOSOPHICAL VIEW OF THE SOIES. 


The platform for the data processing of the 80ies is an analysis of the 
single data item; where it is born, generated, transported, stored, 
processed and where and how it is presented, and how it can be aggre- 
gated to the next information level. One of the most obvious shortco- 
mings of the systems described earlier, was the lack of defined 
aggregation levels and data reduction levels. Detail transactions are 
of interest only up to a certain (management ) level, and will represent 
a tremendous overhead when carried forward on all processing levels. To 
capitalize on this recognition, it is necessary to define each data item 
with reference to it's organization homestead. Definitions also have to 
be made for establishing, maintenance and transaction responsibility. 

In the same way, procedures and policies for the use of data items 
outside it's origining domain must be established, since all items are 
readily available from a technological point of view. The process of 
setting up a responsibility/right-to-use structure, is done over time 
and in line with the on-going development of organization, responsibi- 
lity, delegation, decentralization and localization. 


In this way, the data structure is integrated into the city's organiza- 


tion pattern. 


The system concept can be constructed based on the same general prin- 


ciples. 


Instead of envisioning unified systems within each of the cities’ 


divisions, the systems are exploded into autonomous system elements for 


- data entry - data transportation 
- data storing - data processing 
- data retrieval - data presentation. 
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A combination of the different system elements will often with little 


effort provide the desired solutions. 


The interaction between the system elements, whether the elements are 
implemented on the same technology or different technologies, is based 
upon the standardized data items, and standardized methods for moving 
data between technologies. The explosion of the classic all-comprisning 
system concept into functional elements, makes adaptions to individual 
and local needs easier, and the external characteristics are flexible, 
as the funcionalized elements contain less obstacles to the practical 
implementations. It is also possible to standardize processing charac- 
teristics, eliminating the needs to design new processing routines for 
new tasks and new data items. By processing it is here meant processing 
to change register data into new data before conversion into information 
(e.g. traditional payroll batch processing). A data processing system 


deals with raw material, work in process and finished goods inventory. 


During the 60ies and 7Oies it was a recognized practice to gather all 
single transactions for the different system areas for a common and 
unified processing in a huge mass transaction system prior to the final 
results. The uncritical transport of single transactions to the regis- 
ters of the large systems has made these systems unsuitable as manage- 
ment tools. Through a flexible and localized application of data entry, 
storing, retrieval and presentation, transaction data can be handled on 
a low organization level. Instead of sending the total transaction 
volume on to the next level in the organization, the data entry system 
will make aggregates to the next management level. The transactions can 
be stored in its system of origin for the purpose of e.g. statistical 
processing. On an expection basis single transactions are forwarded one 
or more levels up (e.g. payroll transactions). The distributed concept 
complies with the need for authorized information retrieval, both verti- 


cally and horizontally. 
As data processing in the 60ies and 7Oies focused on quantities, the 


focus of the 80ies will be on improved quality and productivity in 


retrieval, transportation, analysis and presentation of information. 
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RMIT STUDENT DATA BASE 


The Student Data Base and its peripheral systems 
were developed and introduced by staff of the 
Royal Melbourne Institute of Technology. The 
project was supervised by Mr. N.F. Riedl, 

Data Base Administrator and E. de Graauw, Senior 


Systems Analyst. 
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DESIGN OBJECTIVES FOR THE RMIT STUDENT DATA BASE 


The RMIT Student Data Base was designed to satisfy 


the following basic requirements. 


l. The recording, in on-line mode, of the 


Academic progress of 12,000 students. 


2. The capacity to enrol most of these 


students over a three week period. 


3. The production of examination lists covering 


all intermediate and final examinations. 


4. The retention of a complete academic 


history for each student. 


5. To provide a basis for resources planning. 


OVERVIEW OF THE RMIT STUDENT DATA BASE 


2.1 Description (See Appendix I for DB Diagram) 
The name RMIT Student Data Base describes both 
a data base containing academic and student 
information, as well as the systems that operate 


on this data base. 


Day to day maintenance of data on the Student Data 
Base is performed using two major programs which 


allow on-line, real-time, processing of student 


.-/2 
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2. 


information and academic information respectively. 


Additional programs are available to process bulk 
information, such as examination results, in batch 


mode and to produce a large variety of reports. 


Student information held on the data base provides 

a complete profile of current and historical, 
academic and personal details, for each student who 
attended courses during the past years. Once a 
students' most recent records reach a certain age, 
all of his information is archived (unloaded to tape 
and, possibly, microfiche) and only an extract of his 
original record, including a microfiche reference, is 


kept on-line for further use. 


Academic information describes course structures, 


including past and future courses. 


Subjects are recorded as part of course years and 
stages and full details are available as to how 
subjects may be taken, who may take the subjects .and 
study periods involved. Provision is made for sub 
division of subjects into units, with similar 
information being recorded for units as for subjects. 
Examination details which may be recorded for subjects 
and units include such items as intervals at which 
intermediate examinations are due and number of 

papers per examination. 
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3% 
Technical Aspects 
The Student Data Base was set up using the HP 


Image data base package. 


Because most of the information on the data base 

is subject to various conditions and relationships, 
special access modules were designed and written by 
RMIT staff, which incorporate the logic needed to 
take these requirements into account. As a result 
RMIT programmers can concentrate on processing the 
data without the need to get involved in basic data 
collection techniques. The following is an 


example of the technique used:- 


In any semester most students are studying only for 
some of the subjects they enrolled for at the beginning 
of the academic year. Those subjects have been 
defined in the Student Data Base as "current" for 

that semester. Whether a subject is current depends 
on the starting year, starting semester and duration 

of the subject. Maximum duration was set at four 


semesters. 


Data Base access modules have been developed which will 
extract, for a given student, the subjects that were 


current in any semester or year for a specified course. 


Another example is the use of special modules to extract 
"current" academic information from the historical 
course data. 


~-/4 


Course information is retained after courses have 
been phased cut, because student records on file 
may still refer to these courses. This 
necessitates data base course structures which can 


represent the various stages of course development. 


Thus users may set up details of future courses 


without enrolments taking place in these courses. 


Or a gradual phasing in or out of course years and 


stages may be represented. 


And, finally, courses may be phased out entirely so 
that no enrolments can take place, although full 


course details are available for reporting purposes. 


All of this is controlled by a dating system which 
defines the total period over which a course, course 
year, stage, subject or unit is available as well as 
the periods over which different versions of the same 


are in use. 


INFORMATION ON THE STUDENT DATA BASE 


Student Data 
Student Data is recorded under different headings to 
assist with the access and maintenance of information 


on file. The groups of data are listed below. 


sald 
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Personal Details - Name, addresses, etc. 


Historical addresses - Recorded as a result of address 
changes. 


Statistical details - Employment, residential and 
educational status. 


Financial details - Annual record of fees due 
and paid. 

Award details - Historic record of all awards 
presented. 

Prize details - Historic records of prizes 


obtained by students. 


Course details - One set of details for each year 
for each course enrolment per 
Student, containing details such 
as course code, study mode, study 
load, enrolment year, etc. 


Subject details - One set of details for each subject 
enrolment per student containing 
details such as subject number, 
course code, enrolment year and 
semester, study mode and result. 

Unit details - One set of details for each unit 
enrolment per student containing 
details such as unit number, 


subject number, enrolment year 
and semester, study mode and result. 


Course Data (See Appendix IT) 

The academic data structures in the Student Data Base 
permit a true representation of course structures as 
defined in the RMIT calendar, complete with elective 
structures in use in different course. This information 
is linked to academic data recorded for individual 
students, thus making possible the production of 


various academically oriented reports such as 


examination stationery. 
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6. 
A structure of academic data groups, similar to 
student details, provides for economic and 


versatile processing facilities. 


The main data groups are listed below. 


- These are distributed over several 
groups which provide historical 
details, basic course details 
such as course description and 
structural details which link 
subjects to relevant years and 
stages. 


Course details 


Subject details ~ These are distributed over several 
groups which provide historical 
details, basic subject details, 
such as name of subject, structural 
details, which lists units that 
belong to a subject, and 
examination details which indicate 
the number of examinations and 
timing of examinations per subject. 

Unit details - These are distributed over several 

groups which provide information 
similar to that available for 
subjects as outlined above. 


DATA STATUS CONCEPTS 


General Description 

Information on the Student Data Base is in a state of 
flux. From the moment a student enrols, his enrolment 
details determine where he fits into the student profile. 
Depending on wether he is an internal or external 
student, doing Course A or Course Z, full time or 

part time mode, etc., etc., his name may or may not 
appear on various reports, notices, examination 
Stationery, etc. 


Every change to his status, such as a subject 


cancellation,receipt of results, re-enrolment, leave 
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wks 
of absence, etc., may affect the way the next 
process (report, update, etc.) treats his 
records. It is therefore important to be aware 
of the major status conditions that may occur 


and their effects. 


Student Status 
This is a major indicator which determines the 
overall standing of a student. It takes the 


following values. 


- Current 

This is a student who is currently attending 
classes. The student may be enrolled in several 
courses at once, in which case cancellation of one 
course will not affect his current status. 
Depending on further sub classifications this 
student will appear on most standard printouts. 


Other status possibilities are 


Concessional (Enrolment at RMIT subsidiary to 


enrolment elsewhere). 


Leave of Absence 


Unsatisfactory 


Inactive 
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4.4 


- Deleted 


- Archived 


Enrolment Status 


This status is based on how a student is currently 


enrolled in a course or each of several courses. 


Enrolment status determines the following:- 

- Year of enrolment (used to identify current 
and historical enrolment). 

- Year or Stage of Course 

~ Study Mode (Internal, External, Mixed) 


- Study Load (Full Time, Part Time, Single Subject). 


Subject/Unit Currency per student (See Appendix IIT) 


Subject/Unit Currency is a definition that was 
developed to enable identification of Subjects and 


Units that have reached a certain stage of completion. 


The information on which this currency is based is 
for each Subject or Unit: 
- The year of enrolment 
- The starting semester 


- The duration in semesters. 


Using the above information it is possible to define 
which Subjects/Units are, or were, current at any 


point in time. In practice it was found that two 
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9. 
types of currency stood out as a basis for further 
refinement. 
Thus, to extract all Subjects and Units that a 
Student is (or was) enrolled in any year, we use: 
Year Currency "A Subject or Unit is current in 
any given year if the study period for the Subject 


or Unit takes in at least one semester in that year". 


For the purpose of selecting Subjects and Units 

that may be due for examination in a particular 
semester, we use: 

Semester Currency "A Subject or Unit is current in 
a given semester if part or all of the study period 


for the Subject or Unit coincides with that Semester". 


To further determine whether an examination is due for 
a particular Subject or Unit enrolment, the examination 
details include an item called EXAM-SEMESTERS, which 
specifies the number of semesters required to be 
completed in the Subject or Unit beofre the 

examination is due. This permits users of the system 
to define intermediate examinations. A number of 
formulae have been developed which are used to 
determine enrolment currency, exam currency, re- 


enrolment currency, etc., using the above criteria. 


Currency of Academic Data (See Appendix II) 


Due to the historical nature of the academic data on 
file, it is necessary to ascertain that student 


details are related to academic data for corresponding 
.-/10 
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The following definitions of currency apply. 


- Academic Definitions of Current Course 
This is a Course which includes the year 


specified as ‘current’ in its period of currency. 


- Academic Definitions of Current Subject 


This is a Subject which includes the year 


specified as 'current' in its period of currency. 


- Academic Definition of Current Unit 
This is a Unit which includes the year specified 
as ‘current’ in its period of currency. 

Note that in the above definitions current year may 


be any year specified for this purpose. 


Example of Student Data Currency 


The last page in this chapter contains a typical 
academic student data structure, representing 
schematically the type of structure that exists on 


the Student Data Base. 


From this structure the following information 
may be extracted. 
a. This student has attempted three courses. 


b. He is currently (1980) studying subjects in 
Courses B and C. 


c. This year (1980) he is enrolled for 
Subjects CBS2 (Unitized Subject) 
CBS3 
ccss 
CCS6 
ccs? fll 
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and units 


ell. 


CBS2U1 
CBS2U2 
CBS2U3 
cCcS7U1 
CCS7U2 
CCS7U3 
CCS7U4 


b. This semester (Semester 2, 1980) he is engaged 


in the 


following Subjects and Units (Note: 1/2 


means starting semester is 1 and duration is 2 


semester): 


Subjects 


Units 


CBS3/1/2 
CCS4/2/2 
Ccs5/1/2 
CCS6/2/1 
CCS7/0/0 (Unitized Subject) 


CCS7U2/2/1 
CCS7U3/2/2 
CcS7U4/1/2 


Note in the last example that if CCS3/1/1 had 


been recorded as CCS3/2/3, this subject would 


have been current in semester 2, 1980. 
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TYPICAL ACADEMIC STUDENT DATA STRUCTURE 
a ALA SO IRUCIURE 


MSTUDENT 
COURSE-A 
COURSE-A 
COURSE-A 
ASTUDENT, COURSE-B 


COURSE-B 


COURSE-C 


COURSE-C 


COURSE-C 


DSTUDENT-COURSE 


DSTUDENT-SUBJECT 


CAS1/1/1 
cas? /1/2 
(YR=75) CAS3/2/1 
CAS5U1/1/1 
AS4/1/1 —cassv2/1/2 
CAS5/0/0 CAS5U3/2/1 
CAS6/1/2 


CAS7/1/1 
(R=77 << caso/1/1 
CAS9/1/2 


(YR=76) 


(YR=79 Jm<——~CBS1/1/1 
CBS2/0/0 CBS2U1/2/2 


BS2/0/0 CBS2U2/1/1 
(rnsio)=——cnesy 1/9 ~~ 0BS203/1/1 
CS1/2/1 
eye = cca 


Ccs3/1/1 
(YR=79)—<— 0842/2 


CCS5/1/2 
(¥R-80)<——c086/2/1 CCS7U1/1/1 
ia 
CCS7U3/2/2 
CCS7U4/1/2 


DSTUDENT-UNIT 
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ENROLMENTS 


5.1 


Enrolment Data Base (See Appendix IV) 


The enrolment system reduces input data handling 


to a minimum. 


This is achieved through the use of an enrolment 
data base. The enrolment data base contains copies 
of data which was printed on enrolment forms for new 
and returning students. For new students the 
enrolment information consists of data transferred 
from applications processed by the Admissions 

System and academic details extracted from the 


Student Data Base. 


For returning students the enrolment information is 


taken from their records on the Student Data Base. 


The data in the enrolment data base is used to speed 
up on-line enrolments as explained in a later 


chapter. (5.4) 


Students who are not shown on any of the enrolment 
files may be enrolled by overriding the normal data 
checks. This procedure permits the enrolment of 
students who enrol before the addition data has been 


processed or who do not enrol via the Admissions system. 
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Enrolment Forms 

Details printed on enrolment forms include Subjects 
and Units that new students are expected to Study in 
the first year or stage of their course. 

Preprinting of subjects and Units can be valuable 
for the following reasons: 

Reduction in Keying - if the preprinted subject 

and unit details are correct, they need not be 


keyed again. 


Early Enrolment Statistics - Any saving in 


processing time will speed up the production of 


enrolment statistics. 


Fewer Errors - If less data is transcribed manually, 


fewer errors will occur. 


For returning students the selection of Subjects 

and Units for preprinting poses serious problems at 
RMIT, as a result of loosely defined course structures, 
insufficient knowledge of Subjects and Units completed 
at printing time and the large number of students who 


"straddle" course years and stages. 


Although the system is capable of preprinting most 
Subjects and Units for returning students, due to the 


above problems this facility is currently not used. 


AY ie be 
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5.4 


15. 
The only Subjects and Units that are preprinted for 
returning students are those that they have started 
in the preceding year and have not yet completed 
in terms of the total duration of these Subjects 


and Units. 


Data Priorities 


The enrolment process is designed to satisfy the 


following requirements: 


While enrolments are in progress, the Academic 
departments and Planning Branch need information on 
total numbers of students enrolled to-date in 


various categories. 


The enrolment details required for this are treated 


as high priority data, to be processed on-line. (PART I) 


The remainder is processed in batch mode (PART II). 


Note, that PART I details may be batched if necessary. 


On-Line 
A specially designed enrolment form is in use which 
clearly identifies the on-line and batch input data 


areas. 


When a student hands in a completed enrolment form, 
the keyboard operator enters the Student Number shown 
on the form, or, if the student is a new student, the 


Application Number. 
.-/16 
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16. 
Depending on the type of number submitted, the 
system will access either the admission data or 
the returning student data on the enrolment data 
base and display all of the information that was 


printed earlier on the enrolment form. 


The operator modifies the details shown on the screen 
as required and adds any missing PART I details from 
the form. This tends to involve mainly Subject 


information. 


The system then checks the data and reports on errors 
found. When the data has been corrected to a 
satisfactory extent, and provided the data is not 
rejected entirely, due to serious errors, the 


operator indicates that the data is to be processed. 


NORMAL and FAST Modes 
To provide for greater flexibility in the on-line 
process, the system allows operators to specify 


"FAST MODE" incase of peak loads. 


In NORMAL mode the system updates the Student Data 
Base directly with data received from the key board 


operator. 


In FAST mode the data submitted by the operator is stored 
in a holding file and used to update the Data Base in 
batch mode at a later stage, when demands on the 


computer are less. 
.-/17 
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When a number of operators are keying enrolment 
information simultaneously, any number of them 
may be using one or other of the input modes 


described above. 


R4 19 





RMIT STUDENT DATA BASE DIAGRAM APPENDIX I 
DPERSONAL- INFO MSURNAME (AUTO) MCOLLEGF. 


DSTUDENT-PRI MPR DCOURSE-INFO 


DSTUDENT-STATS DCOURSE-YR __ 





DSTUDENT-F INANCE DCOURSE-SUBJECT 





MSTUDENT DSTUDENT-ADDRESS 





DSUB —- INFO 






DSUBJECT-*XAM 


tf 


DSTUDENT-COURSE MCOURSE 











DSUBJ —-UNiT 


DUNIT-INFO 


DSTUDENT-SUBJECT MSUBJECT 





DSTUDENT-AWARD MAWARD DUNIT-EXAM 


Y 
4 


19/8/81 
E.de G. 


R4 20 


APPENDIX II Page 1 of 2 


STUDENT DATA BASE COURSE STRUCTURES 
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STUDENT DATA BASE SUBJECT STRUCTURES 
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An Introduction to CCITT Recommerdation X.21 


Bill Baddelev 
Hewlett Packard 
Commercial Svstems Pinewood 


This paper is an introduction to CCITT Recommendation X.21. The 
recommendation specifies a new data communications interface 
which vou will probably encounter soon if vou haven't already. 


At the present time, most data communications among remote 
terminals and computer svstems are carried over the public 
switched telephone network or over leased telephone circuits. 
The telephone network has evolved over many vears and is an 
excellent medium for voice transmission. When people started 
connecting computers and terminals over long distances, the 
telephone network provided a readily availble, though not an 
optimal, connection medium for digital signalling. Computer 
svstems and terminal equipment are tvpicallv connected to the 
public switched telephone network or leased telephone lines 
through an interface which is referred to by the label RS-232 or 
V.24. This interface tvpe has been around for quite some time 
and is commonly available on modem and terminal equipment. 


An organization of devoted to international cooperation in 
telecommunications, the CCITT, is an international advisory bodv 
which deals with telephone and telegraph communications. The 
CCITT issues recommendations for services and implementation of 
services. There is a series of CCITT recommendations (the 
"V-series" recommendations) for the connection of data terminal 
equipment or DTE (the category DTF includes terminals and 
computer systems) to the telephone network through a modem. The 
connection point to the telephone network is called the data 
circuit terminating equipment, or DCF. The standard connection 
between terminals or svstems and the telephone network is 
described in CCITT recommendation V.24 and the FIA (the U.S. 
Flectronic Industry Association) RS-232. The 25-pin connector 
which you mav have seen on vour terminal cable or computer system 
is the standard connector for this interface. The V.24 or RS232 
connection carries signals between the terminal or computer and 
the modem. These signals include the transmitted and received 
data signals, timing information and control signals which 
constitute a dialog between the modem and the computer concerning 
the state of the connection. For leased telephone circuits, the 
V.24/RS-232 connection carries all of the information needed 
between the modem and the svstem or terminal. The V.24u 
recommendation specifies the function of each of the data and 
control circuits in the interface, and the dialog between the 
terminal/svstem and the modem/DCF. For switched telephone 
connections, some PTTs offer automatic calling units. cCCTTT 
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recommendation V.24 also describes the standard interface between Comparison of CCITT Recommendations v.24 and X.21 
a system or terminal and the automatic calling unit (the FIA _ 

specification is RS-366). This interface uses the same 25-pin 

connector as the V.24 modem interface with redefined signal 

lines. The V.24 recommendation specifies the dialog between the . 

svstem/terminal and the automatic calling unit for establishing V.24 X.21 


connections. 
DTF oC | 


The telephone network is being replaced for some classes of data 
communications traffic by public data networks. There is a lot 
of information in the computer press these davs about the new 
public data networks and the new international standards for 
these data networks. Depending on where vou are located, vou mav 
have heard of either X.25 or X.21 or both. The CCITT has issued 
a series of recommendations (the X series) which deal with data 
communications networks. The X series of recommendations deal 
with services on networks which are specifically designed for 






Auto Call 
Unit. 





data communications. There are quite a few public data networks Distance: ¢< 20 Metres > 1000 Metres 
now in operation, and more services are planned for introduction 
within the next few vears. Speed: < 20 Kbit/sec. > 100 Kbit/sec. 


These networks can be broken into two principal categories 
according to the tvpe of service which thev offer. One tvpe is 


Circuit-Switehed, where the connection between two svstems or Signals: <= 31 signals <= 7 signals 
terminals is equivalent to a hardwired connection once it has : 
been established through the network. Fxamples of circuit Connectors: 1-2 25-pin 1 15-pin 


switched networks are the Nordic Public Data Network in Denmark, 
Finland, Norway and Sweden and the DATEX-L network in the Federal 
Republic of Germany. The other tvpe of network is 
Packet-Switched. Packet switched networks support multiple 
virtual connections through the network over a single DTF/DCE 
connection. 


The CCITT X.21 recommendation describes an interface between Data 
Terminal Fquipment (terminals and svstems) and Data 
Cirevuit-terminating Fquipment for svnchronous operation on public 
data networks. This interface replaces the two-connector, 
multiple signal interface of V.24 with a simpler set of signals, 
a smaller connector, and improved electrical characteristics 
(fig. 1). 
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The X.21 interface is better able to meet the requirements of 
current svstems for data communications than is V.24 in terms of 
speed and distance between the svstem and the network port 
interface. The speeds of service in public data networks under 
the CCITT X recommendations are easilv met bv the X.21 interface, 
the fastest being 48 kbits/sec. For this reason, X.21 is 
graduallv replacing the V.24 interface. 


The CCITT X.25 recommendation, which covers packet-switched data 
networks, specifies the X.21 interface as the electrical and 
mechanical interface between the DTF and DCE. The X.25 
recommendation will be covered in more detail later in this 
session. 


In addition to the electrical and logical definitior of the X.21 
interface, the CCITT recommendation describes logical procedures 
for the operation of the interface in a circuit-switched network 
and in leased-circuit applications. 


The circuit-switched network procedures are broken into four 
phases: the quiescent phase, when no connection exists between 
the local’ station and anv remote station; the call establishment 
phase, when either the DTF starts a call or the DCF signals an 
incoming call; the data transfer phase, and; the call clearing 
phase. The circuit-switched network procedures are verv much 
like the procedures one uses with the switched telephone network. 


During the quiescent phase, the telephone is on-hnook. In the 
X.21 case, the svstem/terminal-and the network signal their 
respective states of readiness to establish a connection through 
the network. 


The call establishment phase, in the case of the telephone 
conversation, begins when one lifts the receiver and dials 2 
number or when the telephone rings, signalling an incoming call. 
In the X.21 network, the terminal/svstem signals to the DCF that 
it is preparing to issue selection signals; the DCF responds bv 
Signalling "proceed to select", and then the PTF issues a 
selection signal sequence specifving a remote station and/or 
network services. An incoming call is announced bv the DCF to 
the DTE/svstem/terminal. All cases of call collision (incoming 
and outgoing calls at the same time) are resolved in favor of the 
outgoing call. If one dials a busv station or mis-dial a number, 
vou receive in response a tone or tone sequence, or perhaps a 
recorded message. In the case of an X.21 network, the calling 
DTF receives call progress signals (figure) which indicate whv a 
call is delaved or whv it has failed. These call progress 
Signals are useful in determining a reasonable next action. In 
additon to call progress signals, the X.21 recommendation 
describes optional facilities for transferring information such 
as called line identification to the calling DTF and calling line 
identificaiton to the called DTF as part of the call setup 
procedure. 
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Group 


Group 
Group 
Group 
Group 
Group 
Group 
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X.21 Call Progress Signals 


Meaning 


Terminal Called 
Redirected Call 
Connect When Free 


No Connection 

Number Busv 

Selection Signals Procedure Frror 
Selection Signals Transmission Frror 


Access Barred 

Changed Number 

Not Obtainable 

Out Of Order 

Controlled Not Readv 
Uncontrolled Not Readv 

DCF Power Off 

Invalid Facilitv Request 
Network Fault in Local Loop 
Call Information Service 
Incompatible User Class of Service 


Network Congestion (short term) 
Long-term Network Congestion 
Registration/Cancellation Confirmed 


Redirection Activated 
Redirection Deactivated 


Signals are delav conditions without call clearing 
Signals indicate short-term conditions 

and 5 signals indicate long-term conditions 

Signals are short-term network related canditions 
Signals are long-term network related conditions 
Signals are confirmation signals (with call clearing) 
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Once the call setup is complete, the connection between the 
calling and the called DTFs is transparent. The network 
transfers the states of each station's transmit data line 
bit-for-bit exactly as it appears at the DCF interface. The data 
phase continues until one of the DTFs signals a clear request. 
This is analogous to the conversation part of a telephone call. 


Call clearing is signalled by either end and transferred to the 
opposite end. Following call clearing, the DTF and DCF re-enter 
the quiescent phase. 


The circuit switched public data network has several advantages 
over the public telephone network, having been designed expressly 
for data communications. One clear advantage is automatic call 
establishment (no operator dialling). 


The X-series recommendations include recommendations for a 
uniform international node numbering scheme which is analogous to 
the international telephone numbering scheme. For example, each 
Nordic network connection has a 6-digit network number, which is 
unique within the country. International calls include an 
international prefix, a network/nation code, and a network node 
identification number. Within the Nordic Public Data Network, 
calls are possible among the nations of Denmark, Finland, Norway 
and Sweden. 


Another feature of the new public data networks is fast call 
establishment and high reliability. For example, the Nordic 
Public Data Network specifications state that all calls will be 
set up within 2 seconds, 99% will be set up within 0.5 seconds 
and 90% of all calls will be set up within 0.1 seconds. 
Similarly all call clearing operations will take under 0.2 
seconds, with 90% under 0.05 seconds. This is clearly an 
improvement over the performance of the switched telephone 
network. 


The X.21 call progress signals, described previouslv, provide a 
Clear indication of the status of a given call attempt along with 
information about the probable success of a retrv. 


Additional facilities allow the subscriber to simplify the call 
process by using short-form addresses for commonly called remote 
nodes. Access restrictions can be placed on a given node bv 
Sspecifving optional facilities to bar incoming or outgoing calls. 
A group number facility allows several ports to be accessed from 
the network by a common node address; a central computer can be 
equipped with several ports which, in addition to their unique 
addresses are also accessed via a common national,network number. 
This facility is also referred to as "multiple lines at the same 
address". The Closed User Group facility allows the creation of 
private networks within the larger public data network. If a 
company has several svstems at different geographical locations, 
and has no need to connect them to svstems outside of the 
particular set, then the specification of closed user group 
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membership for each of them eliminates access from computers 
outside the network. The facilitv can also be used in such a wav 
as to restrict the connections from anv node in the greup to onlv 
other group members. It is also possible for a particular node 
to belong to several closed user groups, one of which is the 
default or preferential one. In order to switch from the 
preferential to an alternate closed user group, the selection 
Signal sequence is prefixed with a facility request code 
specifving which alternate group is to be used for the ¢aii 
setup, followed bv the address of the node within that group. 


s. 
The caller receives a call progress signal indicating that the 
call is queued at the remote end. The call redirection facility 
allows one node to temporarilv transfer its address to another 
node; for the period during which this facilitv is activated, al 
calls for the node are redirected automaticallv to the alternste 
node. A call progress signal informs callers that the call has 
been redirected. The Calling and Called Line identification 
facilities provide for verification and monitoring of connections 
made through the network. A node specifving the Charge Transfer 
facilitv is charged for all incoming calls (which are normeily 
charged to the caller). The charge advice facilitv allows a node 
to be informed, following disconnection, of the charges for a 
call. 


Circuit-switched X.21 networks are currently offered in fersark, 
Finland, Norwav, Sweden, F.R. Germanyv, and Japan. Several other 
Furopean nations have X.21 networks in their future plans. 
Further information about the specification and the network 
services is available from the implementing PTTs, and from the 
CCITT (Union Internationale Des Telecommunications, Place des 
Nations, CH-1211 GFNEVF 20, SUISSF). 
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OPERATOR/CONSOLE INTERFACE 
AN ENGINEERING FEEDBACK SESSION 


PRESENTOR 
MICHAEL PAIVINEN 
COMPUTER SYSTEMS DIVISION 


IN MPE III VERSION B.01.00, THE CONSOLE INTERFACE WAS REDESIGNED 
TO PROVIDE A DISTRIBUTED CONSOLE FACILITY BY INTRODUCING THE 
ASSOCIATE, ALLOW, AND CONSOLE COMMANDS. IN ORDER TO PROVIDE 
DIRECTION FOR THE FURTHER DEVELOPMENT OF THE OPERATOR INTERFACE, 
THE AUTHOR WILL BE SOLICITING CUSTOMER INPUT ON THE FOLLOWING 
QUESTIONS: 


1. WHO IS THE "TYPICAL" OPERATOR? WHAT IS HIS/HER COMPUTER 
SCIENCE BACKGROUND? SOPHISTICATION? WHAT SET OF SYSTEM 
CAPABILITIES ARE GIVEN TO THE OPERATOR? 


2. WHAT FUNCTIONS DO THE OPERATORS PERFORM ROUTINELY? WHAT 
ARE THEIR ADDITIONAL RESPONSIBILITIES? WHAT SYSTEM OPERATIONS 
ARE NOT IN THE HANDS OF THE OPERATOR? WHY? 


3. ARE CUSTOMERS USING THE DISTRIBUTE CONSOLE FACILITY? IF SO, 
HOW IS IT BEING USED? IF NOT, WHAT ARE THE PROBLEMS? 


4. WHAT FEATURES OF THE INTERFACE HELP OPERATORS CONTROL THE 
SYSTEM? HOW COULD THE INTERFACE BE IMPROVED TO PROVIDE BETTER 
CONTROL? 


5. HOW WOULD CUSTOMERS LIKE TO SEE THE CONSOLE INTERFACE EVOLVE? 


MORE POWERFUL OPERATOR CAPABILITIES? AUTOMATION OF SYSTEM 
FUNCTIONS TO REQUIRE NO OPERATOR INTERVENTION? OTHER SUGGESTIONS? 
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HP 3000 Security/risk management 


Purpose 

The purpose of security/risk mariagement is 

to maintain operations in planned mode 

to prevent as far as practicable unauthorized 

access to (discovery or modification) of 

program and data files 

to prevent, mitigate or recover from inside or 

outside dysfunctions. 

Environment 

Organizations that can afford an HP 3000 and the support 
staff generally are significant businesses. 

Edp costs vary between 1.5 pct and 5 pct of total costs and 
business related systems may handle 30 pct to 50 pct of company 
revenues. 

The following system illustrate the point. 


Payroll 30 pct plus 
materials purchasing 30 —" " 
accounts payable 30 " " 
materials inventory 10 " " 
general ledger 100 " " 


Hence a 20 Dollar a year business may run 6 to 20 

million through its HP 3000 

my company runs approximately 70 million through and 

we may double that in 12 months. 

Most HP 3000 installations represent a department's 

first or most ambitious step into electronic data 
processing away from manual or service center operations. 

a large portion of system managers have had little or no system 
management responsibilities. 

This presentation is aimed at them and their concerned 
auditors. 

2- 1 

2. The fundamental security devision rule 

decision about security measures should be based on cost 
versus worth. An organization shouldn't spend more to avoid 
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an increase than the libel or expected cost of the incident. 
In mathematical terms 
de(picl) is greater than(de(pi'ci') plus demci) 


where 

de equals discounted expected value 

pi " " probability of incident i 

ci " " cost of incident i 

mci " " cost of mitigation measures for incident i 


No absolutes 

The cedision rule is not a new or original 
concept. It is a game theory rule that 

emphasizes that there are no absolutes. 

That measures short of suicide can't eliminate 
undesired incidents: they can only reduce theire 
probability on their cost. 

Consider a fire in the computer room. It can 

be caused by a dropped cigarette or an electrical 
short or an overheated cooling fan or arson or a 
fire in the next room or one probagated through 
the plenum or false floor. Rules can ban smoking 
but not electrical shorts. 

2-3 

Paperless computer rooms can reduce the source 
of fuel and halon systems can reduce the source 
of oxygen. But how often is the computer room 
the first source of fire in a building. How 

many computer rooms share buildings with chemical 
closets used by cleaning personnel or oily rags 
used by engineers? 

How many computer centers are built on bed rock 
with fire proof walls and no common air conditioning 
equipment? 

How well will these fire retardent measures combate 
and enternally sourced fire and which more probable? 
2-4 

The probability of a computer room fire is very 
low on the order less than 0.1 pct per year. The 
cost of an automatic halon system is 4000 to 
10,000 for a 10' x 15' room. It would imply 

that the cost of the fire totally suppressed 
should be 
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4000/.001 

or 

4,000,000 

if back-up tapes are stored off-site and there 

is a back-up computer access agreement, then it 
is unlikely that the cost of a total hardware 
loss fire would equal 4,000,000. 

It follows that an expensive automatic halon 
system may be a waste of stockholders’ money 

for a business data processing machine. This 

of course may not be true for a real time 

process control computer or an airline reservation 
system. 

This is a reasonable example of applying the 
decision rule. It of course doesn't leave the 
auditors with a sanguine feeling, that I placated 
by installing a 60 handcarried halon system. 

3. Quantification of security costs 

Decisions about security need to be couched in 
reasonable estimates of costs of security systems 
and probabilities of undesired incidents. 

3.1 Security systems costs. 

Security systems can be divided into two arbitrary 
classes 

probability reducers 

cost mitigators 

The following are examples of 

probability reducers, their objectives 

and ball park costs, 


item objective cost range comment 
computer room reduce unauthor- 150- 1000 cheap looks 
locks ized access can be 
jimmied , 
with credit 
card 
door locks reduce unauthor- 100- 300 beveled 
ized access to one time latches can 
files be jimmied 
reduce probabil- with credit 
ity of theft card 


-3- $24 


item 
sentries 


passwords 
account, group, 
user 


item 


item 
terminal 
locks 


objective 


reduce unauthor - 


ized access to 
files 


reduced probabil- 


ity of thef 


reduce unauthor- 


ized access to 
files and 
programs 


objective 


objective 


keep unauthorized 


users from 


accessing system 


cost range 
10,000- 20,000 
per shift per 
year 


1.00- 5.00 
per password 
per change 


cost range 


cost range 
50- 400 


comment 
cheap 

sentry can 
become thief 
can become 
lazy 
effective- 
ness is in- 
versely pro- 
portioned to 
age and 
number of 
cognocenti 
approaching 
comment 

zero after 
three days. 
Low cost and 
low effect- 
jveness 
paswords are 
stored in 
clear text 
in stream 
jobs that 
are not 

lock worded 
and in image 
schema that 
are not lock 
worded. 
Multi user 
paswords 
obviate 
accountabil- 
ity 

comment 

can be by- 
passed with 
second 


terminal re- 
connected to 


PSO 


reduce fire 
probability 
reduce disk wear 


no smoking 


manual fire put out fire 
extinguisher 


tape back-up recover lost 


system files 
item objective 
remote protect back-up 
tape tapes from 
storage local dys- 
function 
hardware recover costs 
insurance of 
disaster 
Internal 
violation of privacy 
manipulations 


fraud ghost vendors and employees 
theft or hardware, information 


1 to? 


50- 200 


15 to 50 

per tape per 

day plus re- 

entry cost at 
1/2 a day per 
person 


cost range 


2- 10 per 
month per 
tape 


same port. 
some smokers 
will violate 
rule. Some 
may quit. 
Good for 
limited fire. 
Reesn't work 
without 
operator. 
Typically 
half a week 
day will be 
lost and will 
have manual- 
ly re-entered 
back-up tapes 
comment 
Should be 
stored 
remotely. Need 
protection 
system. 
Should be 
tested 
episodically 


2 to 5 pct of most large companies 


hardware 

1.5 to 3 
times costs 
the expected 
cost of the 
disaster 


self-insured. 
Read policies 
carefully. 
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External 
fires 
“earthquakes 
bombings 
power failures 
toxic spills 
phone system failures 
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Presentation Abstract 


Presentation Title: RAPID/3000, new from HP: Relational Access, Pro i 
__ CC nt terractive Development, = 


Author(s):______ Jutta Kernke 
Title(s): HP_ Information Network Division _ 
Address: Cupertino, CA 5 


Abstract: (No more than 200 words) 

analyst. data base administrator and end-user. It provides a total solution 
to_80% of transaction requirements. RAPIN/3000 provides: Relational ad-hoc 
inquiry and comprehensive, customized reports to the end-user and decision- 


- - more inform ; ' Simplifies ses 


productivity in development, testing and implementation - - more applications 


faster: Reduces time spent in debugging, maintaining and documenting=- 
more time away from i ines' A relati 


separates the user-world from -- 
more information resources for all users. RAPID/3000 - - - to get more 


information to more management faster and 
easier! 
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FAST EDITING 
fit 
PROGRAM DEVELOPMEHT 
USTHG «A 


FULL SCREEN EDITOR 
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» INTRQDUCTICH, 


In most camputer sy 


levelapment. which is 


FULL SCREEH EBPITIANG 


FLEems text handling 


4 form of text handling, 


‘DOP resources, The choice of 3s good text 


if praguctivity. 


fe wil went lmok at 


rditors, 


the advantages and disadvanta: 


amount. 


Wi 
ite 
mu 


Progr aim 


kinds of text 
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FULL SCREEN EDITING 


ome gee wee wee eA cee ome ms en me ee ae et om oe me tee ee UP Oey oe ae 


The first text editers considered three sequential files. The first file 
momtains the old text to be modified; a second File contains cammands ta alicu 
thie deletian, replacement and addition of Full lines. The result is 3 new 


Zequential file, cantaining the carrected text. 


fn exemple of this editor type is QUERY ’s ‘ALTER’ command to modify & procedure. 


line numbers, given in the ctommands, must 


~4 
a 
» 
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i 
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(nly few of the sequential editors have string handling capabilities. 
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2. major enhancement to the Sequential editor waz the 


capabilities. In general these include 


ms 


- the possibility ta jump back and forth ain the text 1 


- string handling capabilities Ce.q. FIHG "string" s 


Interactif editers asct on ane single lire gstoa time. Sa. if the user 


see the context af the changes he 15s intraducing, 

listed after entering some edit commands. 

Most interactif editors work on a copy of the original text Ca uork Files. The 
of copying the original text into the wark File and wice versa, takes 


operation 


= considerable amount of time and system resources. On the other hand, working 
diréctly on che original text, is an hazardous task ta undertake since & mere 


t. 


1G 
x 


tyoing error could destroy large parts of the t 


lternate solution 


i 
ml 


Regulariy taking a copy of the text solves the problem. An 


is to copy the file, at the start of each edit run, and save the wark file a5 


the new text at the end. This saves the time of 3 “KEEP saperation . 
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terminals became large pact of 


a 


Ht the time, when more intelligent 


the editing task could be performed bu the terminal instead oa 


The editer sends a full page of text to the the serecen, This text 15 edited 
Wzing the edit features of the terminal ¢e.g. ‘INSERT LINE’, ‘GELETE CHAR’ >. 


after editing af the terminal sends the full page Back tx 


the computer and this one sends 3 mew page to the terminal. 


The advantages of this method are obviously: 


~ 3 good oversight of the caomtext of the changes performed, 


— 3 very natural way af editing Cit looks like editing on a sheet of paper). 


~wery powerfull if the terminal uged has good editing capabilities. 


The disadvantages are: 


and forth takes 2 considerable amaunt of 


W 
it 
= 
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- 
a 
“ 
ui 
1 
ey 
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mi 
cr 
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" 
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&.g. gight seconds to send 3 24 lines by 80 characters page at 2400 baud. 
This transmission is performed twice, even if only a single character is ta 
be modified. 

~ Q safisticated and hence expentive terminal ts mesded 


~ The amount of text that cam be added to 5s page if dependant on the amount oF 


local store in the terminal. 
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FULL SCREEH EDITING 


fl 


5, THE FULL SCREEN EDITOR. 


To overcome the disadvantages of the full page editor, the editor itself can 
emulate the sophisticated edit features of an expensive terminal, The user then 
The editor accepts one 


edits the whole file at a time instead of anly one page. 


edit command ¢this can be 4 single key stroke? and performs the edit an the text 


a 


File and on the scree 


A typical example of this editor type is the edifor available on the HP 200 


system. 


The advantages of such 4 system are: 
~ atl the advantages of a full page editor. 
- considerable savings of time. 


- The only special features needed on the terminal are 
. cursor positioning 
_ character ahd line insertion and deletion 
Qii otner teatures can be emulated by the editor. 


This allows to implement a full sereen editor on a law cast terminal. 


FULL SCREEN EDITING 
Many additional features are added to text editors. Some of them are: 
- The capability of compiling directly from the work File. 
- isc space saving by record compression. 
~ Handling of MACRO’s. 
-~ Autematic generation of program code. 
- Word processing capabilities. 
- Lasp constructs. 


- Canditianal editing. 


FULL SCREEN EDITING 


v. FSEDIT. 
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FSEDIT ifs a full screen editor for the HP3000 computer svtems. 


Tt will run on any terminal from the HP264x and HP262x families, imcluding the 


low cost HPe6e!. 
Its main features are: 
~ Full screen editing as described stove, 
- Single key-strake commands. 
- direct compile, prepare and run from the work file. 
- word processing capabilities, 
- COROL source generation. 
- macro handling. 


—- powerfull command set. 


These and other features make FSEDIT an easy to use tool, that allows 


increase in productivity of programmers and other users, 


PSEDIT is developed by 


SYDES N.Y. TEL O02°4662913 
A, GOSSETLAAN 300A TELERA 62435 


B 1720 GROOT BI JGAARDEN 
BELGIUM, 


Demonstrations of FSEDIT are given ast the SYDES N.V. Booth. 


a high 
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Summary of: RELATIONAL DATABASE-CONCEPT, CONSEQUNCES FOR ORGANIZATION 
AND MANAGEMENT-STRUCTURES 


1. What is a releational database 


If you look at EDP-concepts, you will find in almost all cases an 
hierarchically structured file organization. Data sets were organized in 
different stand-alone files, which were accessed through SEARCH-ITEMS. Most 
of the FILES were designed for a single application. The structure of this 


RELATIONAL DATABASE-CONCEPT., File-system (i.e. the PATHES to the DATA-ENTRIES) has been defined before 
implementing the data sets (i.e. in ISAM, HISAM, KSAM files etc.). 
CONSEQUENCES FOR ORGANIZATION AND MANAGEMENT-STRUCTURES EXAMPLE : find "city of Berlin" 


if ZIP-CODE is the search-item to all cities, you could find 
the city of Berlin only, if you knew the zip-code. 


Only with SORT/MERGE you could reassemble your file, so that it would 
satisfy a different QUERY. 
Uwe HINRICHS 
If changes vould become more complex, you would have to reorganize your 
file-system for this particular application. that means building up 
nev files with new PATHES and reflecting these changes within the 
program/system. 


With the appearance of database systems this became much easier. But still 
you needed a strong, hierarchical structure of organization at the 
beginning. The advantage was that your DATA didn't fit for just one 
application but for your application system in total. 


EXAMPLE : a whole application system ---(> COMPANY 


a single application --{C SALES 
MATERIALS MANAGEMENT 
FINANCE 
etc. 


The understanding of a database system was originally a mass storage file 
system, in which the data sets were application independent. 

Still you had to organize the pathes within the database in the beginning, 
so that you had a regulated structure, which couldn't be modified without 
any problem. 


EXAMPLE : implemented references between : SALES --{> FINANCE 


postulate references between : SALES ---(> MATERIALS MANAGEMENT 


Uwe HINRICHS 
To fullfill this postulate, you needed a modification of the database struc- 


SAUER- I NFORMATIC 
K 35 ture or you could use a QUERY-SYSTEM. 
ica But a disadvantage of QUERY systems is the time used to search items in a large 
2350 NeEUMUNSTER database throughPATHES, which have not been implemented (SCHEMA). 
Arar MERMORY There are different types of such traditional DATABASE-SYSTEMS; for Example : 


HIERARCHICAL and NETWORK DATABASES. 
Both TYPES OF DATABASE SYSTEMS have the same features of a traditional file 
management organization : 
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a regulated structure 

- modifying and adding of references and programs ale very difficult/time 
consuming 

- cycle of lifetime about 5 years, because the requirements are changing 
(trouble shouting) 

- must of top/down approach 

- batch approach 

- price/performance for modifiying and adding 


The relational database system, now, has a completely different approach. 

The structure of TRADITIONAL FILE-SYSTEM/DATABASE-SYSTEM has to be defined 
first, before you start solving your detail problem. With RELATIONAL DATABASE 
SYSTEMS (RDBS) the strcture is variable : 

you still might define temporary relations like you could with traditional 
QUERY SYSTEMS. However, the most important feature of a RDBS is the capability 
of learning relations (PATHES). 


The capability of modifying, deleting and adding new relations at any time 
is a feature of this system. 


EXAMPLE : available relation ---(> SALES - FINANCE 
postulate relation ---[f> SALES - PRODUCTION PLANNING 


You can define this relation easily with the new variable path information. 
The advantage of relational database systems are : 


- a variable structure without hierarchical levels 

- easy to modify, delete and add relations and programs 

- bottom up approach 

- lifetime of the systems without a limit, because the system is flexible 
to adapt new requirements immediately 

- full dialogue approach 

-- high quality of price/performance 

- high data quality 

- high automation level 


2. Organizational Aspects 


With a traditional computer organization you need a general concept before 
you can start programming and building the FILE-/DATABASE-SYSTEM in the 
field (i.e. manufacturing firms, administrations etc. ). 

The main chapters of this concept are : 


- analysis of given structures 

- definition of future requirements 
- definition of implementation steps 
- description of analysis 

- implementation 


The general concept - also the analysis - is divided into two parts. 


first part organizational concept of the analysed field 


related to field structure and needs 


second part : organizational concept of EDP 


related to Hard- and Software-Systems (Software-tools). 


ere eS) 
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These steps are time consuming with the additional disadvantage that 
the result is always just a snapshot of an existent system, possibly 
reflecting some future requirements. 


With a traditional concept there is a strong interdependence between 
the first and the second part and there fore it is important to analyze 
the complete system-in order to get an optimal, general concept which 
covers future requirements, too. Before starting to implement the 
application system with a traditional file/or database system it is 
necessary to have the organizational concept completed. The traditional 
TOP/DOWN APPROACH is usually used for this type of concept. 


EXAMPLE : Organization Analysis 


GENERAL 
CONCEPT 


FIELD EDP 
STRUCTURE CONCEPT 





SALES MATERIALS FINANCE 
MANAGEMENT 





You must modify the whole structure and analyse the whole system again, 
if you modify or add relations between elements of the defined concept. 


The great advantage of a relational database system is the variability in 
organization structure. The steps of system analysis are flexible, because 
you don't need a general concept that is structured in a first and second 
part like the general concept. 


The main steps of realization are here : 


- description of given structure with future requirements 
- implementation 


vel 4 


etc. 


TS y 


fn Wh. 


If new requirements arise you will implement them immediately without 
reflection on previous written Software. The problem is now restricted 
to generation of new field structure elements. 


The system isn't a snapshot any longer, but a living system. Using this 
technique will now allow you to use the BOTTOM UP APPROACH for your 
organizational work. Thisis in fact the most efficient way to proceed 
because the level of quality of your DECISION-DATA is depending on the 
level of quality of your BASIS DATA. 


The features of this organization method are : 
- horizontal structured information ---[> relations between the field 


elements 
_ vertical structured information ---[> Management Information System 
- high level automation 
~ all kinds of information available immediately 


EXAMPLE : Relational Concept 


MATERIALS FINANCE 


TOP FIELD 
MANAGEMENT MANAGEMENT 
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INTRODUCTION 


The purpose of this presentation is to discuss techniques 


facilities which: 


1) 


2) 


3) 


4) 


isolate the programmer from specific hardware con- 
Siderations 


provide for data and device independence 


allow the programmer to deal with a logical rather 
than a physical view of data and devices 


allow computer resources to be reconfigured, re- 
placed, rearranged, reorganized, restructured or 
otherwise optimized either automatically by system 
utilities or explicitly by a system manager or 
database administrator, without the need to rewrite 
programs. . 


The evolutionary development of these techniques will 


be reviewed from a historical perspective, and the specific 


principles identified will be applied to the problem‘of pro- 


ducing formatted screen applications which will run on any 


type of CRT. 
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WHAT IS A COMPUTER? 


As you already know, a computer consists of one or more 
electronic and/or electromechanical devices, each capable of 
executing a limited set of explicit commands. For each type 
of device some means is provided to allow the device to re- 
ceive electrical impulses indicating the sequence of commands 
it is to execute. In addition to commands, most of these 
devices can receive electrical impulses representing bits of 
information (commonly called data) which the device is to 
process in some way. Nearly all of these devices also pro- 
duce electrical impulses as output, which may in turn be 
received as commands and/or data by other devices in the 
system. 

Nowadays, most devices also have some form of "memory" 
or storage media where commands or other data can be recorded, 
either temporarily or semi-permanently, and a means by which 
that data can later be received in the form of electrical 
impulses. 

The tangible, visible, material components which these 
devices are physically made up of is generally called com- 
puter hardware. Any systematic set of instructions describing 
a useful sequence of commands for the computer to execute 
can be called computer software. As we will see later, soft- 
ware can be further subdivided into system software, which 
is essentially an extension of the capabilities of the hard- 
ware, and application programs, which instruct the computer 


how to solve specific problems, handle day-to-day applications, 
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and produce specific results. 

Originally it was necessary for a computer operator to 
directly input the precise sequence of electrical signals by 
setting a series of switches and turning on the current. 
This process was repeated over and over until the desired 
sequence of instructions had been executed. 

By comparison with today's methods of operating comput- 
ers, those earlier methods can truly be called archaic. Yet 
the progressive advancement of computer systems from that 
day to this, however spectacular, is nothing more than a 
step-by-step development of hardware and software building 
blocks, an evolutionary process occuring almost entirely 


during the past 25 years. 


ENGINEERING AND AUTOMATION 


I think we mostly take for granted the tremendous com- 
puting power that is at our fingertips today. How many of 
us, before running a program on the computer, sit down and 
think about the details of hardware and software that make 
it all possible? For that matter, who stops to figure out 
where the electrical power is coming from before turning on 
a light or using a household appliance? Before driving a 
car or riding in an airplane, who stops to analyze how it 
is put together? 

Probably none of us do, and that is exactly what the 
design engineers intended. You see, it is the function of 


product engineering to build products which people will buy 
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and use, which usually means building products which are easy 
to use. The fact that we don't have to think about how some- 
thing works is a measure of how simple it is to use. 

Wherever a process can be automated and incorporated 
into the product, there is that much less that the consumer 
has to do himself. Instead of cranking the engine of a car, 
we just turn a key. Instead of walking up 30 flights of 
stairs, we just push a button in the elevator. 

It's not that we are interested in being lazy. We are 
interested in labor-saving devices because we can no longer 
afford to waste the time; we have to meet deadlines; we want 
to be more efficient; we want to cut costs; we want to in- 
crease productivity. We also want to reduce the chance for 
human error. By automating a complicated process, we 
produce consistent results, and when those results are 
thoroughly debugged, error is virtually eliminated. We can 
rely on those consistent results, which sometimes have to 
be executed with split second timing and absolute accuracy. 
Without reliable results there might be significant economic 
loss or danger to life and limb. Imagine trying to fly 
modern aircraft without automated procedures. 

Automation also facilitates standardization, which 
allows interchangeability of individual components. This 
leads to functional specialization of components, which in 
turn leads to specialization of personnel, with the attendant 
savings in training and maintenance costs. And because the 


engineering problem only has to be solved once, with the 


U1 5 


benefits to be realized every time the device is used, more 
time can profitably be spent coming up with the optimum 


design. 


BUILDING BLOCKS 


In my opinion, the overwhelming advantage of automating 
a complicated process is that the process can thereafter be 
treated as a single unit, a "black box" if you will, in 
constructing solutions to even more complicated processes. 

Later, someone could devise a Hatter version of the 
black box, and as long as the functional parameters remain 
the same, the component could be integrated into the total 
system at any time in place of the original without destroying 
the integrity of any other components. 

It is this "building-block" approach which has. permitted 
such remarkable progress in the development of computer hard=- 
ware and software. As we review the evolution of these 
hardware/software building blocks, keep in mind that the 
chronological sequence of these developments undoubtedly 
varied from vendor to vendor as a function of how each per- 
ceived the market demand and how their respective engineering 


efforts progressed. 
ONE STEP AT A TIME 


Even before tne advent of electronic computers, various 
mechanical and electro-mechanical devices had been produced, 


some utilizing punched card input. Besides providing an 
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effective means of input, punched cards and paper tape repre- 
sent a rudimentary storage medium. Incorpor atina paper tape 
and card readers into early computer systems not only allowed 
the user to input programs and data more quickly, more easily, 
and more accurately (compared with flipping switches manually), 
but on top of that it allowed him to enter the same programs 
and data time after time wie hardly more effort than enter- 
ing it once. 

The next useful development was the "stored program" 
concept. Instead of re-entering the program with each new 
set of data, the program could be read in once, stored in 
memory, and used over and over. 

This concept is an essential feature of all real comput- 
ers, but it would have been practically worthless except for 
one other essential feature of computers known as internal 
logic. We take these two features so much for granted that 
it's hard to imagine a computer without them. In fact, with- 
out internal logic, computers really wouldn't be much good 
for anything, since they would only be able to execute a 
program in sequential order beginning with the first instruc- 
tion and ending with the nth. Internal logic is based on 
special hardware commands which provide the ability first of 
all to test for various conditions and secondly to specify 
which command will be executed next, depending on the results 
of the test. In modern computer lanjyurges, internal logic 
is manifest in such constructs as IF statemant<«, GO TO 


statements, FOR loops, and Subroutine calls. 
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But at the stage we are discuss.nq Liiere were no modern 
programming languages, just the language of electrical signals. 
These came to be represented as numbers (even letters and 
other symbols were given a numeric equivalent) and programs 
consisted of a long list of numbers. 

Suppose, for example, that the numbers 17, 17, and 14 
represented hardware commands for reaiing a number, addiny 
another number to it, and storing the result, respectively, 
and suppose further that variables A through Z were stored 
in memory locations 1 through 26. Then the program steps 
to accomplish the statement "give 2 a value equal to the sum 
ot X and Y" might be expressed as the following series of 


numbers, which we will call machine instructions: 


wh 


17, 205. 114-254. 4% 26 
In essence, the programmer was expected to learn the language 
of the computer. | 
A slight improvement was realized when someone thought 
to devise a meaningful mnemonic tor eaci: hardware command and 
to have the programmer write programs using the easier-to- 
remember mnemonics, as follows: 
READ, 24, ADD, 25, STOKE, 26 
Or perhaps even 
READ, X, ADD, Y, STOKE, Z. 
After the programmer had described the logic in this 
way, any program could be readily converted to the numeric 
form by a competent secretary. tut Since tne Conversion was 


relatively straightforward, it would be automated, saving the 
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secretary some very boring work. A special computer program 
was written, known as a translator. The mnemonic form, or 
source program as it was known, was submitted as input data 
to the translator, which substituted for each mnemonic the 
the equivalent hardware command or memory location, thus 
producing machine instructions, also known as object code. 
Translators required two phases of execution, or two passes, 
one to process the source program and a second to execute 
the resulting object code. Once the program functioned 
properly, of course, it could be executed repeatedly without 
the translation phase. 

It would have been possible for the hardware engineers 
to keep designing more and more complicated hardware commands, 
and to some extent this has been done, either by combining 
existing circuitry or by designing new circuits to implement 
some new elemental command. Each new machine produced in 
this way would thus be more powerful than the last, but it 
would have been economically prohibitive to continue this 
type of development for very long and the resulting machines 
would have been too large to be practical anyway. 

Engineers quickly recognized that instead of creating 
a more powerful command by combining the circuitry of existing 
commands, the equivalent result could be achieved by combining 
the appropriate collection of commands in a miniature program. 
This mini-program could then be repeated as needed within an 
application program in place of the more complex command. Or 


better yet, it could be kept at a fixed location in memory and 
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be accessed as a subroutine just the same as if it were 
actually a part of each program. 

Another approach was to use an interpreter, a special 
purpose computer program similar to a translator. The inter- 
preter would accept a source program in much the same way as 
the translator did, but instead of converting the whole thing 
to an object program, it would cause each hardware command to 
be executed as soon as it had been decoded. 

Besides requiring only one pass, interpreters had the 
added advantage of only having to decode the commands that 
were actually used, though this might also be a disadvantage, 
since a command used more than once would also have to be de- 
coded more than once. 

The chief benefit of an interpreter lay in its ability 
to accept mnemonics for commands more complex than those 
actually available in the hardware, and to simulate the 
execution of those complex commands through the use of sub- 
routines. In this way, new commands could be implemented 
without any hardware modifications merely by including the 
appropriate subroutines in the interpreter. This step marked 
the beginning of system software. 

In addition, source programs for nearly any computer 
could be interpreted on nearly any other computer, as long as 
Someone had taken the time to write the necessary interpreter. 
Interpreters could even be written for fictional computers 
or computers that had been designed but not yet manufactured. 


This technique, though generally regarded as very inefficient, 
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provided the first means of making a program transportable 
from one computer to another incompatible computer. 

It is possible, of course, to apply this technique to 
translators as well, allowing a given mnemonic to represent 
a whole series of commands or a subroutine call rather than 
a single hardware instruction. Such mnemonics, sometimes 
called macros, gave users the impression that the hardware 
contained a much broader repetoire of commands than was 
actually the case. 

Implementing a new feature in software is theoretically 
equivalent to implementing the same function in hardware. 

The choice is strictly an economic one and as conditions change 
so might the choices. One factor is the universality or fre- 
quency with which the feature is likely to be used. Putting 

it in hardware generally provides more efficient execution, 

but putting it in the software is considerably easier and 
provides much greater flexibility. 

The practice of restricting hardware implementation to 
the bare essentials also facilitated hardware standardization 
and compatibility, which was crucial to the commercial user 
who wanted to minimize the impact on all his programs if he 
should find it necessary to convert to a machine with greater 
capacity. Beginning with the IBM 360 series in 1964 "families" 
of compatible hardware emerged, including the RCA Spectra 70 
series, NCR Century series, and Honeywell 200 series, among 


others. 
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Each family of machines had its own operating system, 
software monitor, or executive system overseeing the 
operation of every other program running on the machine. 

In some systems, concurrent users were allowed, utilizing 
such techniques as memory partitioning, time-sharing, multi- 
threading, and memory-swapping. Some form of job control 
language was devised for each operating system to allow the 
person submitting the jobs to communicate with the monitor 
about the jobs to be executed. 

Introducing families of hardware did not solve the 
problem of compatibility hetween one vendor and the next, 
however, a problem which could only be solved by developing 
programming languages which were truly independent of any 
particular piece of hardware. 

Since the inventors of these so-called higher-level 
lanquages were not bound by any hardware constraints, an effort 
was made to make the languages as natural as possible. FORTRAN 
imitated the language of mathematical formulas, while ALGOL 
claimed to be the ideal language for describing algorithmic 
logic; COBOL provided an English-like syntax, and so on. 

Instead of having to learn the computer's language, a 
programmer could now deal with computers that understood his 
language. Actually, it was not the hardware which could 
understand his language, but a more sophisticated type of 
translator-interpreter known as a compiler. 

To the degree that a particular language enjoyed enough 
popular support to convince multiple vendors to implement it, 


programs written in that lanquage could be transported among 
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those machines for which the corresponding compiler was 
available. 

The term compiler may have been coined to indicate that 
program units were collected from various sources besides the 
source program itself, and were compiled into a single function- 
ing module. Subroutines to perform a complex calculation such 
as a square root, for example, might be inserted by the comiler 
whenever one or more square root operations had been specified 
in the body of the source program. 

Embedding subroutines in the object code was not the 
only solution, however. It became more and more common to 
have the generated object programs merely "CALL" on subrou- 
tines which were external to the object program, having been 
pre-compiled and stored in vendor-supplied "subroutine librar- 
ies". This concept was later extended to allow users a means 
of placing their own separately-compiled modules in the library 
and accessing them wherever needed in a program. 

I should mention that an important objective of any 
higher level language should be to enable a user to describe 
the problem he is solving as clearly and concisely as 
possible. Although the emphasis is ostensibly on making the 
program easy to write, being able to understand the program 
once it has been written may be an even greater benefit, 
particularly when program maintenance is likely to be 
performed by someone other than the original author. 

It is well-known that program maintenance occupies a 


great deal of the available time in the typical data 


A 
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processing shop. Some studies estimate the Figure at over 

50% and increasing. In order to be responsive to changing 
user requirements, it is essential to develop methods which 
facilitate rapid and even frequent program changes without 
jeopardizing the integrity of the system, and without tying up 
the whole DP staff. 

To avoid having to re-debug the logic every time a change 
is made, it is often possible to use data-driven or table- 
driven programming techniques. The portion of the program 
which is likely to change, and which does not really affect 
the overall procedural logic of the program, is built into 
tables or special data files. These are accessed by the 
procedural code to determine the effective instructions to 
execute. 

The most common example in the United States, and 
perhaps in other countries as well, is probably the table of 
income tax rates, which changes by law now at least once a 
year. The algorithm to compute the taxes changes very rarely, 
if at all, so it does not have to be debugged each time the 
tables change. In simple cases 1ik6 this, non-programmer 
clerks might safely be permitted to revise the table entries. 

In more sophisticated applications, tables of data called 
logic tables may more directly determine the logic flow 
within a program. The program becomes a kind of interpreter, 
and elements in the logic table may be regarded as instructions 
in some esoteric machine language. Such programs are gener- 


ally more difficult to. thoroughly debug, but once debugged 
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provide solutions to a broad class of problems without ever 
having to revise the procedural portion of the program. 

Sometimes, logic-controlling information is neither 
compiled into the program nor stored in tables, but is pro- 
vided to the program when it is first initiated or even during 
the course of execution, in the form of run-time parameters 
or user responses. The program nas to be pre-programmed 
to handle every valid parameter, of course, and to gracefully 
reject the invalid ones, but this method is useful for cutting 
down the number of separate programs that have to be written, 
debugged, and maintained. For example, why write eight 
slightly different inventory print programs, if a single 
program could handle eight separate formats through the use 
of run-time options? 

Incidentally, program recompilations need not always 
cause alarm. Through the proper use of COPY code, programs 
can be modified, recompiled, and produce the new results with- 
out the original source program ever having to be revised. 
This is made possible by a facility which allows the source 
program to contain references to named program elements stored 
in a COPY library instead of having those elements actually 
duplicated within the program. A COPY statement is in 
effect a kind of macro which the compiler expands at the 
time it reads in the source program. 

For example, if a record description or a table of values 
appears in one program, it is likely to appear in other 


programs as well. It is faster, easier, safer, and more 
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concise to say "COPY RECORD-A." or "COPY TABLEXYZ."" than 

to re-enter the same information again and again. And if 
for some reason the record layout or table of values should 
have to be changed, merely change it in the COPY library, 
not in every program. 

By changing the contents of a COPY member in this way 
and subsequently recompiling selected programs in which the 
member is referenced, those programs can be updated without 
any need to modify the source. If procedure code is involved, 
the new COPY code only need be debugged and retested once 
rather than revalidating all the individual programs. 

Where blocks of procedural code appearing in many programs 
can be isolated and separately compiled, however, this would 
probably be better than using COPY code. For one thing, the 
separate modules would not have to be recompiled every time 


the procedural code was revised. 
BITE-SIZE PIECES 


Breaking a complex problem into manageable independent 
pieces and dealing with them as separate problems is a 
valuable strategy in any problem-solving situation. Such a 
strategy has added benefits in a programming enviconment: 


4. Smaller modules are typically easier to understand, 
debug. and optimize. 


2. Smaller modules are usually easier toc rewrite or 
replace if necessary. 


3. Independent functions which are useful to one appli- 
cation are often useful to another application; using 
an existing module for additional applications cuts 
down on programming, debugging, and compilation time. 
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4. Allowing applications to share a module reduces memory 
requirements. 


5. Having only one copy of a module ensures that the 
module can be replaced with a new version from time 
to time without having to worry that an undiscovered 
copy of an older version might still be lurking 
around somewhere in the system. 

The fact that a routine only has to be coded once 
usually more than compensates for the extra effort that may 
have to go into generalizing the routine. The more often 


it's used, the more time you can afford to spend improving it. 
SYSTEM SOFTWARE 


Functions which are so general as to be of value to 
every user of the computer, such as i/o routines, sort 
utilities, file systems, and a whole host of other utilities, 
are usually included in the system software supplied by the 
hardware vendor. Just what facilities are provided, how 
sophisticated those facilities are, and whether the vendor 
charges anything extra for them, is a matter of perceived 
user need and marketing strategy. Sometimes vendors choose 
to provide text editors and other development tools, and 
sometimes they don't. Sometimes they provide a very powerful 
data base management system, sometime only rudimentary file 
access commands. And so on. 

When hardware vendors fail to provide some needed piece 
of software, it may be worthwhile for the user to write it 
himself. If the need is general enough, software vendors may 
rush in to fill the void; or perhaps user pressure will even- 
tually convince hardware vendors to implement it themselves. 
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In this way, many alternative products may become 
available, and the user will have to evaluate which approach 
he wishes to take advantage of, based on such factors as cost, 
efficiency, other performance criteria, flexibility of oper- 
ation, compatibility with existing software, and the 


comparative benefits of using each product. 


PRINCIPLES OF GOOD SYSTEM DESIGN 


In case you may need to design your own supporting 
software, or evaluate some that is commercially available, 
let's summarize the techniques which will permit you to 
achieve the greatest degree of data, program, and device 
independence. I have already given illustrations of most 
of the following principles: 


1. Modularity--Conceptually break everything up into 
the smallest modules you feel comfortable deal- 
ing with. 


2. Factoring--Whenever a functional unit appears in 
more than one location, investigate whether it is 
Feasible to "factor it out" as a separate module 
(this is analogous to rewriting A*B+A*C+A*D as 
A®*(B+C+D) in math). 


3. Critical Sections--Refrain from separating modules 
which are intricately interconnected or sub- 
dividing existing modules which are logically 
intact. , 


4. Independence--Strive to make every module self- 
contained and independent of every external 
factor except as represented by predefined 
parameters. 


5. Interfacing--Keep to a minimum the amount of commu- 
nication required between modules; provide a 
consistent method of passing parameters; make 
the interface sufficiently general to .allow 
for later extensions. 
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6. Isolation--Isolate all but the lowest-level modules 
from all hardware considerations and physical 
data characteristics. 

7. Testing--Test each individual module by itself as 
soon as it is completed and as it is integrated 
with other modules. 


8. Generalization--Produce modules which solve the 
problem in a general way instead of dealing with 
specific cases. Be careful, however, not to 
over-generalize. Trying to make a new technology 
fit the mold of an existing one may seem like 
the best modular approach, and the easiest to 
implement, but the very features for which the 
new technology has been introduced must not 
become lost in the process. 


EXAMPLE--When CRT's were first attached to com- 
puters they were treated as teletypes, a class of 
i/o devices incompatible with two of the CRT's 
most useful features: cursor-addressing and the 
ability to type over existing characters. Putting 
the CRT in block-mode and treating it as a fixed- 
length file represents the opposite extreme: the 
interactive capabilities are suppressed and the 
CRT becomes little more than a batch input device, 
a super-card-reader in effect. 


9. Standardization--Develop a set of sound programming 
standards including structured programming methods, 
and insist that each module be coded in strict 
compliance with those standards. 


10. Evaluation--Once the functional characteristics 
have been achieved, use available performance 
measurement methods to determine the areas which 
most need to be further optimized. 


11. Piecewise Refinement--Continue to make improvements, 
one module at a time, concentrating on those with 
the largest potential for improving system perform- 
ance, user acceptance, and/or functional 
capabilities. 


12. Binding--For greater flexibility and independence, 
postpone binding of variables; for greater 
efficiency of execution, do the opposite; pre- 
bind constants at the earliest possible stage. 
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BINDING 


As the name suggests, "binding" is the process of tying 
together all the various elements which make up an executing 
program. Binding occurs in several different stages ulti- 
mately making procedures and data accessible to one another. 

For example, the various statements in an application 
program are bound together in an object module when the 
source program is compiled. Similarly, the various data 
items comprising an IMAGE data base become bound into a 
fixed structure when the root file is created. A third 
case of binding involves the passing of parameters between 
separately compiled modules. 

Remember that at the hardware level, where everything 
is actually accomplished, individual instructions refer to 
data elements and to other instructions by their location in 
memory. The "address" of these elements must either be built 
into the object code at the time a program is compiled, be 
placed there sometime prior to execution, or be provided 
during execution. Likewise, information governing the flow 
of logic can be built into the program originally, placed in 
a file which the program accesses, passed as a parameter when 
the program is initiated, or provided through user inter- 
action during execution. 

Binding sets in concrete a particular choice of options 
to the exclusion of all other alternatives. Delayed binding 


therefore provides more flexibility, while early binding 
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provides greater efficiency. Binding during execution time 
can be especially powerful but at the same time potentially 
critical to system performance. In general, variables should 
be bound as early as possible unless you specifically plan 

to take advantage of leaving them unbound, in which case 

you should delay binding as long as it proves beneficial and 
can still be afforded. Incidentally, on the HP 3000, address 
resolution between separately-compiled modules will occur 
during program preparation (PREP) except for routines in 

the segmented library, which will be resolved in connection 
with program initiation. If your program pauses initially 
each time you run it, this run-time binding is the probable 


cause. 


A SPECIFIC APPLICATION 


About five years ago, we were faced with the problem 
of developing a system of about 300 on-line application 
programs for a client with no previous computer experience. 
Their objective was to completely automate all record- 
keeping, paper-flow, analysis, and decision making, from 
sales and engineering to inventory and manufacturing to 
payroll and accounting. The client had ordered an HP 3000 
with 256K bytes of memory and had already purchased about 
20 Lear-Sigler ADM-1 CRT's. About 12 terminals were to be 
in use during normal business hours for continuous inter- 
active data entry; the remaining eight terminals were 


primarily intended for inquiry and remote reporting. 
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Up-to-date information had to be on-line at all times using 
formatted screens at every work station. Operator satisfac- 
tion was also a high priority, with two- to five-second 


response time considered intolerable. 


DISCUSSION QUESTIONS 


Based on the “principles of good system design" sum- 
marized earlier, what recommendations:-would you have made 
to the development team? 


At the time, HP's Data Entry Language (DEL) seemed to 
be the only formatted screen handler available on the 
HP 3000. Consultation with DEL users convinced us it 
was rather awkward to use and exhibited very poor re- 
sponse time. Also it did not support non-HP character- 
mode terminals. 


We elected to write a simple character-mode terminal 
interface, which was soon expanded to provide internal 
editting of data fields, and later enhanced to handle 
background forms. We presently market this product under 
the name TERMINAL/3000. You've probably heard of it. 


The compact SPL routines reside in the system SL and 

are shared by all programs. The subroutine which inter- 
faces directly with the terminals is table-driven to 
ensure device-independence. By implementing additional 
tables of escape sequences, we have added support for 
more than a dozen different types of terminals besides 
the original ADM-1i's. 


If we were faced with a similar task today, would your 
recommendations be any different? 


After completing most of the project, we did what should 
have been done much earlier: we implemented a CRT forms 
editor and COBOL program generator which together auto- 
mate the process of writing formatted-screen data entry 
programs utilizing TERMINAL/3000. We call this approach 
"results-oriented systems development"; the package is 
called ADEPT/3000. Programs which previously took a 
week to develop can now be produced in only half a day. 


Since we were using computers to eliminate monotonous 
tasks and improve productivity for out clients, it was 
only natural that we should consider using computers to 
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Swallow, Kenneth P., Elements of Computer Programming 


From what you know of TERMINAL/3000 and ADEPT/3000, how (New York: Holt, Rinhart and Winston, Inc., 1945). 
do these products enable a programmer to conform to the ; _ 
principles of good system design? Weiss, Eric A. (ed.), Computer Usage Fundamentals ‘New York: 


McGraw-Hill Book Co., Inc., 1969). 


TERMINAL/3000 itself: modular, well-factored, single 
critical section, device-independent, independent of 
external formats, simple 1-parameter interface, table- 
driven hardware isolation, well-tested, generalized, 
optimized for efficiency, run-time binding of cursor- 
positioning and edit characteristics. 


ADEPT/3000: produces COBOL source programs that are 
modular, well-segmented, device-independent, and 
contain pre-debugged logic conforming to user-tailored 
programming standards; built-in interfaces to 
TERMINAL/3000 and IMAGE/3000 (or KSAM/3000) isolate 
the programs from hardware considerations and provide 
device and data independence. 
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HOW TO GET MORE FROM YOUR CORE MEMORY 
HOW TO GET MORE FROM YOUR CORE MEMORY 
OR 
CFS/3000 
A CORE RESIDENT FILE SYSTEM 


PIERRE SENANT 


Pierre Senant 


A LITTLE HISTORY ... 


A data processing system ordinarily uses three main types of 
memory, which have each a different speed level. Besides, the 
byte cost of these types of memory varies with their access 
speed. Here are the three tynes of memory in decreasing cost 
order : 


1. Core memory. The latest technology uses integrated circuits 
and the access time is calculated in micro-sgeconds. The 
purpose of this memory is to contain program seqments during 


P. SENANT the time they are executed, as well as a vart of the data to 
COGELOG be handled. The life time of these elements in memory is 
ETUDE ET REALISATION DE SYSTEMES INFORMATIQUES between a few milli-seconds, and many hours. 


AVENUE DE LA BALTIQue, Z.A. DE CourRTABOEUF 
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2. Auxiliary memory : Magnetic discs are normally used. The . The amount of code that can be put in memory at a given 
time to access information is calculated in milli-seconds. time is larger. This implies a fall in data segment 
The purpose of this kind of memory is to save programs and swapping, which dramatically reduces the disc overhead 
data to be used during a given period, which can be from a and increases the throughput of the system. 


few minutes to many months. 
- The amount of data handled in one time can theoretically 


3. Archival memory : This can be done through many devices, but be increased, by using large file system buffers. However 
the most common is the magnetic tape. Since the access to this technique gives disappointing results, especially in 
data is performed serially, the access time to data can be random access. 


from a few seconds to many minutes. This low-cost type of 


memory is used as back-up memory, and for saving all data Most data processing applications are now using more and more 
currently unused. interactive mode, instead of batch mode. Improving batches is 
important, but improving on-line programs is vital. Batches can 
When we consider the evolution of these different tynves of run in off-peak hours, and most of the time the jobs can be 
memory during the last past years, we observe a fall in prices done. But in interactive applications, each second of response 
for all types, but a particular drop for the core memory. time lost must be multiplied by the number of users, and 


employer's time is getting expensive. 


This drop has considerably changed the physionomy of data 


processing systems during the last years. The HP-3000 So, the benefit of increasing core memory comes almost 

system remained in the swim. When it came out in 1972, the exclusively from improving the programs flow. Suppose we 

maximum memory size supported was 128 K bytes. The model of could increase indefinitely the core memory size, we would 

1981 can support up to 4000 K bytes. reach a critical point where adding a memory module would 
not affect the response time, because all program segments 

In addition, this trend will vrobably be confirmed in the are already in core. 

next years, and an HP-3000 with 20.000 K memory will be 

common soon. The advantages of the increase of the core Another important factor bears heavily on the response time 

memory are evident : disc accesses due to transactions of apolication programs, 


An on-line program using a data base system (IMAGE 3000 for 
example) may be very greedy in disc accesses. This overhead 
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is independant of the number of program segments in memory 
and it becomes the actual bottleneck. This makes unprofitable 


an increase of core memory. 


When a system has reached this level of evolution, one vossible 
way to reduce the overhead is to suppress some disc accesses. 
At first sight, this load seems to be incompressible. If we 
assume the files and the data bases have been correctly 
organized, and application programs have been written with 
shrewdress , what can we do ? 

However, when we examine all kinds of files involved in an 
application, we are surprised by their diversity, in the size, 
in the organization, and in the usage. 

In fact, most of them are small enough, and are so frequently 
accessed that we would do better to make them core-resident. 
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NOW THE PRESENT : CFS/3000 


The idea to make some files core-resident might not be very 


original, but it certainly remained a dream until to day. 


Now the dream becomes reality with CFS/3000. 
In my opinion, a real in-core memory file system must follow 


the following principles. 


. It must be program independant. 
Allowing programming people to decide if a file must be 
core-resident or disc resident would be catastrophic. 
. A core resident file must be accessible from all processes. 
The duplication of data is not acceptable. 
. It must be reliable. Data integrity must not be affected, as 
well as the process independancy. 
. It must respect all security and privacy provisions of the 
file system, as well as those of subsystems (IMAGE, KSAM). 
. It must be fully controlled by the System Manager, who must 
know at any time. 
- the name and the sizes of core-resident files 
~ the total memory size used 


- access frequency of any data-set. 


In addition, the System Manager can decide to put inor out of 


core-memory any file at any time without disturbance in operation. 


The conception of CFS/3000 has been founded upon these 


principles. 
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This product is intended to optimize both batch programs and 


on-line programs. In all cases, a good knowledge of application 


programs and system 


management will be required. 


. In a batch environment, the execution time can be dramatically 


reduced. It will be strongly recommended to run one program at 


a time, in order 


. In an interactive 


accurate. 


You will have to us 
how busy your discs 
accessing data file 
If the swapping is 

file to make core-r 


response time. 


to devote the maximum core-memory to data files. 


environment, the tuning must be more 


e the utility program IOSTAT2 to determine 
are, and what they are doing (swapping or 

s). 

low, you may use CFS/3000. You will select the 
esident by considering their impact on the 


With CFS/3000 you will be able to make trials without stopping 


the daily operation 


As a first step, you may declare core-resident some small files 


frequently accessed like. 


. Tables of parameters 
. Automatic master data sets (IMAGE) 


. KSAM key-files 


In a second step, you will be able to design your future 
applications, by taking into account this new possibility. 
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Opening Address 


1. Introduce who you are: D.A. Saunders, B.Sc., M.I.C.S. OR sac 


2. Thank audience for attending, as this is the last session and we 
realise a number of them would like to wind up. 


3. Introduce subject matter: 

a) We are going to talk about a Financial & Management Accounting 
System which utilises the most up to date System Software 
facilities available. 

b) Computer Manufacturers invest substantial amounts of money in 
the Research & Development of Systems Software - however the 
development of application Software to match the System Software 
in capability is mostly out of the reach of the user due to its 
high cost. 

c) This normally would have led to a totally unbalanced state in 
the development of advanced end-users software. However, 
imaginative systems' designers with the background and backing 
have clutched the challenge so that now there are some application 
systems matching the system software capability. 

d) These systems in general are either produced by a Software House 
so that costs can be snread among many users or by extremely 
large concerns that can justify the expenditure. 
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History a 


In 1971 when EUROSPAN started, the COMPUTER installations were in the 
main ‘Main Frame' oriented. We approached our design of EUROSPAN by 
looking at the following: 


a) STRUCTURE OF FILES 

b) ACCOUNTING PRINCIPLES 

c) HISTORICAL COMPUTER DESIGN OF 

ACCOUNTING SYSTEMS 

In structuring our files we recognised that the system should be capable 
of handling a multi division or multi company type structure. Indeed our 
first customer was a service bureau and needed such a structure. Systems 
Analysts traditionally designed systems which broke the accountants 
normal conventions which he was used to (i.e. non double-entry bookkeeping 
and seperate ledger systems whereas he was used to 3 in 1 type systems). 
This led to an alienation of accountants to computers so we brought the 
computer back to the liking of the accountant by designing an integrated 
double system for him. This design was not done by computer people but 
by accountants with the help of computer people. We were fortunate in 
having a qualified accountant who also was an expert in the computer 
field. 
From 1971 the system evolved from a basic accounting system to a more 
complex one include such facilities as automatic creditor payments and 
cost accounting. This changing design brought us up to 1977 when we 
realised the significance of the emereging mini computer market place. 
Which market has brought computing power to companies heretofore unable 
to afford it. 
We decided to completely rewrite EUROSPAN to allow for Online facilities 
whilst still retaining it’s much vaunted and accepted structure. In 
addition auditors by now were aware of the possibilities and dangers 
of computerised accounts and through consultation with them we included 
new further enhanced security measures into EUROSPAN. 
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Theoretical Frame Work 





There were many implications in designing and producing a truly Onl ine- 
System. Many of you, no doubt, have been presented with semi-online 

(not interactive) type systems that effectively only replaced the punched 
card and we felt that our EUROSPAN should definitely not be confused 

with such systems and should be the tool of the non computer trained 
accountant. 

The implications of such a system needed consideration in the following 
areas: 


- Storage capabilities 

- Hardware and 

- Software Portability 

- Integration of other applications 
- End of Year Problems 

- User Friendliness 

- Speed 

- Security in Multiprocessing 


At that stage also computer manufacturers were introducing and ‘Singing 
about' the new buzz word 'Decentralisation' (naturally this was influenced 
largely by an ever-aware end-user demand owing to their increased 
awareness of computer power) and we took the initiative of designing our 
system to cater for the communications problems that usually exist. 


BILD 


In recognising communications we also took account of multi-international 
requirements by solving those at the same time. The implications of this 
are not technical but conceptual and are as follows: 


a) Currency 
b) Language 
c) Corporate Reporting 
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Methods and Techniques 


In consideration of the implications of online, multi-international 
systems we adopted the following solution taking into account a rigid 
standards system development by one of our sister companies. 


1.) Storage capabilities 


In a ‘multi type’ situation large duplication of data can exist 

So we set out in adapting EUROSPAN to the end-user to perform a 

clear analysis of each Group's/Comoanies'/Divisions' responsibilities 
to cut down on the unnecessary holding of duplicate data by the use 
of a common data base and subsidiary ones. We integrated our 

ledgers into a simple data base. 


2.) ue 

3.) Hardware/Software 
Nowadays functionality depends largely on the joint facilities 
provided both in hardware and software. We did not want a system 
which tied us exclusively to a particular manufacturer or operating 
system as we don't determine that manufacturer's future. We are 
confident that many of you present are in the same frame of mind. 
So we wrote the following facilities ourselves and used an industry 
standard language of COBOL. 


~ Menu Processor 

- Screen Handler 

- Logging and Recovery Routines 
- File Handler 

- Security Routines 


These enabled us to retain a large degree of Manufacturer Independance. 
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4.) Integration of Job Functions/Other Applications 


5.) 


6. 


et 


Trough our menu processor we have the ability to switch from function 
to function inthout having to go back through the menu itself which 
gives the flexibility and ease of use demanded by the discerning 
end-user. In addition we adopted a parameter/table driver system to 
enable the end-user to define their own requirements (e.g. functions, 
languages, help routines, reporting formats) without the painstaking 
job of changing programs for minor requirements. 


End of Year Problems 


Most systems we have come across impose fixed booking periods on the 
end-user and at the end of year before starting a new one cumbersome 
procedures must be carried out in balancing/finalising the old year 
before proceeding with the new. This costs a company real money in 
delayed revenue and has put an unacceptable strain on the data 
processing divisions within companies. 

Through parameters, the EUROSPAN user can determine exactly the periods 
he requires and can post details to previous periods until he finally 
decides to close them off, whilst always having an up-to-date balance 
on all accounts for a period of two years. He can also retain his 
history for ad-infinitum depending on his disc-storage. 


User Friendliness 


It is enough to say that through the use of our menu system and 
breakdown of functions in the familiar way the user is used to using, 
he relates totally to the system. 


7.) Speed 


Speed can be a real ‘bug bear' in any real-time system especially 

with sophisticated processing requirements. We incorporated the 

following procedures to overcome this: 

a) Logical grouping of fields in Data Base Design which afforded us 
less system overhead and additional logical data item space for 
individual requirements. 
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Furthermore grouping of data items eleminates the need to 
concatenate data items and hence reduces system overhead. 
By freeing space on the data base other applications such as 


order processing, fixed assets accounting, stock/warehouse etc. 


control can be incorporated under the one schema. 


Our menu processor enables the user to move between online 
functions without necessarily going through the menu each 
time, carrying across all relevant data. This makes a very 
efficient and fast usage of the system possible. 

Ne have developed screen handling routines with prompt and 
help facility on each field. Online processing is character 
mode, i.e. fields are validated upon acceptance and 

redundant screen input by the user is avoided. Field by field 
processing has proven to be overall faster and more efficient, 
especially in a very large user environment. 

Our file handling routines were also designed for fast input 
and retrieval of data. The dabase design and own logging/ 
recovery procedures that we implemented reduce the overall 
system overhead. 

Finally our concept of defining up to 99 different transaction 
types within the bookings-posting functions, with user-defined 
parameters, reduces dramatically the necessity to input 
recurrent data within logically similar types of transactions 
(e.g. posting invoices, cash etc.). 

The speed of entry and validation is thus very high within 

all areas of postings, as default or predefined values need 
not be entered anymore by the user. 
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8.) Multiprocessing 


One of the major headaches of software designers that multiprocessing 
has brought about, is security and recovery of data. As already 
mentioned, we have developed our own logging techniques. 

The terminal number, user number, date, time, and type of transaction 
as well as the logical end of cycle for transaction cycles are part 

of the log information. One is thus in the position of determining 

the last transaction per terminal as well as any logically incomplete 
transactions. Recovery may be then effected, either from the previous 
data security, or merely by eliminating any incomplete transaction 
cycles from the database, j.e. working backwards. 


Communications 

Communications software and hardware are now readily available. Postal 
links are constantly improving through postal radio developments and 
sattelite communication. 

We have found HP's DS software & H/W a very easy to use and reliable 
tool, within our distributed network applications. 

Our philosonhy in this area is simple. Provide the facility for 
immediate retrieval of relevant data through communications, but 
always ensure that every unit within a network may continue to process 
its own data independantly, at any time. We must subsequently provide 
subsets of the central database to remote locations and update these 
as required daily. The relevant information as to which data is 
required where, is held on file so that again, no redundant transfer 
of data needs to take place. Also a set of reconcilation procedures 
had to be developed to ensure the integrity of all remote databases. 
When communications are across borders, there are also time differences 
to take into account. Here the priority is to enable data exchange 

at the most efficient and also economic time, while ensuring maximum 


data security. 
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10. International pecuie 
Factors are most important in any international system are: fs au 
Sophisticated application software for sophisticated system software 


is now made possible at a price that end-users' budgets can allow, as 


- Currency 
- Language 
: : ‘ i the development costs have been spread over a large number of users. 
- Different accounting periods and fiscal years : . ons | 
; Installation and trial time is also cut short by the fact that EUROSPAN 
- Different balance sheet formats ; 
1S a proven system. | 


- Different reporting conventions 
Different logal considerations to be considered . 
If you have time please come and see us at stand 1. 


We have given everyone of these points considerable attention, as the 
constantly growing list of our multinational users proves. 

We have kept language constants separate from the program code. 
Flexible currency conversion routines have been developed to enable 
the user to define the rules according to the procedures he is used to, | 
and the legal regulations in the respective country. 
Decimal points are not available if the foreign currency does not | 
require them (increased speed of entry). 
EUROSPAN offers multinational concerns the tools to maintain accounts 

in local and remote company format, currency and language, as well 

as providing each company with a number of different reporting, 

budgeting, consolidation and grouping options. 

In addition to this our report generator WHAT-IF integrated with 

EUROSPAN gives the user an additional tool for retrieving data and 

producing new reports in any desired format, as and when necessary. 
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" ABSTRACT : 
A method for high speed digital image processing, using incremental plotters 
is described. This proiect involves the use of computer graphics to 


High Speed Digital Image processing using a Picture-Scanning technique on 


electronically scan a picture and convert the resultant analogue signals to 
Incremental Plotters. 


digital signals, subsequently to be processed on a high resolution TV 


monitor. The picture scanning attachment consists of a high resolution 
optical reflective sensor and associated amplification stages. This is in 
the form of a small probe which replaces the pen and the pen holder in an 
incremental plotter, and thus allows pictures to be scanned and stored as 
digital output for subsequent processing by a digital computer. The 
processing of this digital output could be on a high resolution TV monitor 
or a printer, using the Grey Scale contrast technique. Relative merits of 
this scanning technique are discussed. A special mention jis made of a 
possible interface with the Hewlett-Packard Laser Printer software, where 


the digitising process could be speeded up many fold. 


Ramesh Pancha] 
Hewlett Packard Ltd 
King Street Lane 
Winnersh 

Wokingham 

Berks 

RGI1 5AR 
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INTRODUCTION: 


Digital image processing technology has reached a stage in its development 
where a considerable impact has been made in most technological 

fields. In addition to commercial and military applications, it's impact 

on the medical technology has been far reaching e.g. its use in brain and 

body scanners, where the resultant digital images are processed on a high 


resolution TV monitor. 


A digital image memory and processor offers a wide range of capabilities. 
It can digitise and store image data provide scan conversion, improve 
signal-to-noise ratio (SNR) via frame integration or averaging, detect 
and accumulate image differences, enhance very low contrast images and 
provide an interface between video and digital technologies. A well 
designed system will also have the flexibility to be interfaced with a 
variety of image sensors, computers, displays and recording devices as 
well as provide for software expansion for image analysis applications. 
Cigure 1 is a block diagram showing a state-of-art digital image memory 


and processor with such a range of capabilities. 


As it can be envisaged from above, there are various techniques one can 
employ for digital image processing. This paper examines a very simple 
and inexpensive picture scanning device in conjunction with an incremental 
plotter to digitise a picture and process the image on a high resolution 
TV monitor. The study was a direct result of a requirement for an 
inexpensive method for inputting shaded images to a digital computer. One 
of the projects involved the use of these shaded images in comparing the 
relative merits of Fourier, Walsh and Haar transforms in data compression 


and noise reduction of images. The mathematics involved is rather complex 


and beyond the scope of this paper and hence has been omitted for simplicity. 
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The entire study was carried out in the department of Computer Science at 


Brunel University. 


The outcome of this study offers a good, inexpensive practical avenue for 
digital image processing, and a possible application with the Hewlett 


Packard laser printer is mentioned. 


THE SENSOR AND PLOTTER: 


The picture scanning device, assembled at the Computer Science laboratory 
of Brunel University, consisted of the HEDS-1000 high resolution optical 
reflective sensor (Hewlett Packard 1979), mounted at the end of a smal] 
plastic tube which replaced the pen and the pen holder on the plotter. 
Mounted within the tube was the associated circuitary (see figure 2) 
comprising a current feedback amplifier utilising the sensor's internal 
transistor, thus providing current gain and bias point stability. Further 
gain was provided by an operational amplifier with adjustable output 
voltage level, which allowed for optimum contrast to be selected for any 
given shaded picture. The output from the sensor was converted by an ADC 
(Computer Technology 0000a) which was connected to a Modular One computer 


for storage as a data file. 


The incremental plotter used (Computer Technology, 0000b) was a small 
roller type, rather than the drum or flat-bed construction which was the 


only one available at the time of this study. 


Apart from the low cost aspect of this simple design approach, another 
favourable feature was that it enabled the employment of standard Calcomp 
digital plotter software in driving the modified pen carriage during 


picture scanning. 
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DIGITISED OUTPUT: 


After image processing, the output can be programmatically presented to a 
line printer or a matrix printer using overprinting techniques, (See 
figure 3) with an output voltage swing from the sensor of 8v for a high 
contrast picture, and a noise level of less than 20mv peak-to-peak, a 
considerable number of grey levels can be achieved. In order to test 

the sensor, the digital output was initially processed on a matrix 
printer (Centronix 702) for which sixteen levels of grey were chosen. 
This produced a rather poor quality of overprinted images but proved to 
be sufficient to test the sensor. The subsequent image processing was 


carried out on a high resolution TV monitor. 
PROBLEMS ENCOUNTERED: 


Apart from the poor quality of overprinted images obtained from the matrix 
printer, a major problem area was due to picture wrinkling. As the plotter 
was a roller type, and the pictures were fastened on the plotter paper, 
there was a tendency for wrinkling to occur which caused image defocusing. 

A 0.5mm high ridge caused a 50% drop in reflected photo current. This was 


overcome, for test purposes by using small mint postage stamps (figure 4). 
(The problem would be non-existant on Hewlett-Packard flat-bed plotter 


series where the paper is electrostatically held absoutely flat on the 


plotter. ) 
CONCLUSION: 


The sensor is sufficiently sensitive to detect variations in whiteness 
(or blackness) quite unnoticed by the naked eye. A high resolution is 
achievable which also enables line following and other complex scanning 


routines to be programmed. 
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APPLICATIONS AND FURTHER WORK: 


This technique provides a relatively inexpensive method for digital image 
processing. As a result of a matrix availability on the Hewlett Packard 
laser printer - 2680 software, a special character set with varying levels 
of darkness can be generated. Using IDSCHAR, a character designing program 
provided with the 2680 software, a special set of characters, with each 
character cell showing a varying shade ranging from total white to total 
black can be generated. As there are numerous levels of grey achievable 

by the sensor, these can be associated with the special character set on 
the laser printer and a TV monitor like resolution is achievable, although 


further work in this area is necessary. 


Similarly, the sensor can be used using the primary colour filters and 
data stored for each colour, which can be subsequently integrated on a 
colour monitor. It is also possible to transmit these digital data 


files across a communications network and process the image remotely. 
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A block diagram shows relationship of elements comprising digital image 


memory/processor with random access memory. 
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Figure 3. 
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L010 FORMAT CAL) 
Ceseeeleft 1 & right 9 to convert to 7 bit value 
! LBA ICH 
1 ory 49 
1 Sey 42. 
1 STA TCH 
(Lee ee CHECK FOR N OR FE: 
TF CYCH-EQ-LE)? GOTO 9999 
TF (CXCH.-EQ-LN)D GOTO 20 
COTO 9991 
2.0 CONTINUE 
Cree e READ SIZE OF SQUARE FROM DATAFILE 
READ €3»1020>2TSQUR 
LF CISQUR.LE.O)> GOTO 999% 
TF CLSQUR.GT.128) GOTO 99? 


ICH 
ICH2 


+ ft 
vob 
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10 


CeeeeeREAD SCALING FACTOR FROM TERMINAL 


f-,Eer 
Zz re) 


1.020 


90 


L00 


L050 


200 
LOSS 


997). 
2010 


9999S 
2020 
PIPED 


100 
1000 


100 
1,000 


WRITE (2725) 

FORMAT C' TYRE SCALING FACTOR? ‘7) 
READC 221020) FACTOR 

DO 200 Ji» TSQURK 

READ (371020) (VALUES CI) » L=1 »ITSQUR) 
FORMAT ¢ 9 

DO 100 Td» TSQUIK 

TETCT CI) = VALUES CI) *xFACTOR 

TR CLEICT CED T.0> TPXLCTCL)=0 

TF CXF ICTR) .GT.LS) TEC (LD ehS 
TGREYTFICT CL) +1 

LINEL (2X) = IGREY. CIGREY) 

LINE2 (I) = IGREY2 CIGREY?) 

WRIETE €49 1050) (LIWEL CI) »T1 9 TS SQU > 
CALL CR 

WRITE (4105 50) CLINE? CIDd 9 T= Ly ISQUR) 
FORMAT CLH+s 12842 > 

Chl. CR 

CA. Le 

CONTINUE 

WRITE (41055) 

FORMAT C11 > 

GOTO 10 

WRITE (222010) 

FORMAT (1X» ‘UNKNOWN CHARACTER ' /) 
GOTO 9999 

WRITE (272020) T.SQUR 

FORMAT (1X9 ' MATRIX SIZE OF ‘»sIéy' IS OUT OF RANGE ' 7) 
STOF 

END 


SUBROUTINE CK 

NUL. = 

TCR = 13 

WRITE (4x 10000 TCR 
DO 100 Lleiv io 
WRITE (41000 .NULL 
FORMAT Clee» AZ) 

FREE TUREN 

NI 


SUBROUTINE LF 

NULIL = 0 

TLF = = 10 

WRITE (4710000 TLE 
HO 100 T2113 
WRITE (491000) NULL 
FORMAT CLH+9 Add 

FREE TURN 

END 
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Understanding Hewlett-Packard, a view from the inside 


by 


Jan Stambaugh 


Computer Systems Division 
19447 Pruneridge Avenue 
Cupertino, CA 95014 


Four months ago, I resigned as chairman of the HP3000 International 

Users Group's board of directors to accept a position as manager of 

the quality improvement program for Hewlett-Packard's Computer Systems 
Division. In the past four months, I have learned a great deal about the 
Hewlett-Packard company, a complex yet simple organization which focuses 
on quality and excellence in the design of its products and services. It 
has been both amusing and disturbing for me to realize how little I ever 
really understood about how things work at Hewlett-Packard and why. 


This paper is designed to help customers gain an awareness of Hewlett- 
Packard, its structure, it's management, and it's goals and objectives. 


HP BCG BASIC 
STEVE NG 
ENGINEERING SECTION MANAGER 
HEWLETT PACKARD GENERAL SYSTEMS DIVISION 


SEPTEMBER 21, 1981 


ABSTRACT 


This paper describes the strategy for developing and maintaining a 
competitive, compatible BASIC language and compatible BASIC inter- 
face to tools (e.g., database, data entry, reports, graphics) for 
the Business Computer Group families (125, 250 and 3000). BCG BASIC 
project objectives, features, technology used and conversion aids 
will be discussed. 


BACKGROUND 


It has long been a goal at HP to have a single HP standard for 
BASIC to provide a growth path through the desktop computers to 
the HP1000 and the commercial machines (HP125, HP250 and HP3000). 
However, the implementors on single-user single-language machines 
and those on multi-user multi-language machines differ 
philosophically with respect to the inclusion of operating system 
functions at language level. As a result, we have more than a 
dozen BASICS at HP, most of them are incompatible with one 
another. 


Our near-term goal is to narrow the number of BASICs at HP to two: 
BCG BASIC and TCG BASIC. In August this year, the General Systems 
Division has been given the charter of the BCG BASIC. GSD has the 
total responsibility for developing and maintaining a competitive, 
compatible BASIC language and compatible BASIC interface to tools 
(e.g., database, data entry, reports, graphics) for the Business 

Computer Group families (125, 250, 3000 and future BCG computers). 


OBJECTIVES 
Compatibility across all BCG machines is the primary objective. 


It is difficult to write an application program without uSing any 
tools such as database, data entry and report writers. 


Even if we achieve 100% language compatibility but don't have a 
common interface to the application tools, then it will be 
extremely difficult to transport programs from one system to the 
other. Thus for the BCG BASIC project, we set the following 
objectives: 


Oo TO provide a compatible BASIC language for the HP3000 and 
future BCG products. 


Oo TO provide an upgrade path for current users of BASIC/250, 
BASIC/125 and BASIC/3000. 


Oo To be a user-friendly system in the 250 tradition. 


Oo To provide uniform interfaces to application tools on all 
target systems. 


Oo To provide conversion aids for current 125, 250 and 3000 BASIC 
users ensuring at least 80% automatic conversion. 


FEATURES 


The new ANSI BASIC standard, expected to be adopted in 1982, 
describes a very full and powerful BASIC language. It provides 
the user with capabilities and features previously lacking in the 
language and necessary for large applications. HP needs a 
compatible BASIC across all its product lines, and conforming to 
the BASIC ANSI standard is the best way to accomplish that. 


BCG BASIC will include all of the features specified in the ANSI 
BASIC Level I standard proposed by ANSI-ECMA. In addition, many 
of the better features of the HP250 and HP125 will be implemented. 


Highlights of the BCG BASIC include: 


Identifier names up to 31 characters long 

Named subprograms 

Sophisticated exception handling 

Integrated file system 

Arrays up to six dimensions 

Commercial formatter 

250-like programmer interface 

Built-in application tools for database and Forms Management 
Alphanumeric labels 

IF-THEN-ELSE, WHILE-LOOPS AND CASE constructs 

Templates for reading files written by other languages 
Enhanced string handling 

Support for non-English character sets and collating sequences 


O000000 000000 


TECHNOLOGY USED 


The BCG BASIC will use our Portable Compiler Writing System (PCWS) 
which is an integrated compiler system for a set of Programming 
languages and machine architecture and has been under development 
at HP for the last two years. The PCWS consists of a Common 
Intermediate Data Structure (CIDS), which is source language and 
architecture independent, and a Code Generator for each machine. 
With PCWS, it permits the production of M different languages for 
N different machines with only (M+N) rather than the traditional 
(MXN) programs. 


Other advantages of the PCWS approach include the following: 


1. Provides the user with uniformity across architectures 
for a given language and across languages for a given 
architecture. 


2. Reduce development and maintenance costs. 
3. Increase reliability and efficiency. 


4. A global optimizer can be produced to work on the CIDS 
and hence all compiled languages. 


In order to provide the friendly, interactive environment of the 
HP250, and to eliminate the current problem of having 
inconsistencies between the compiler and interpreter, BCG BASIC 
will be a hybrid interpreter/compiler implementation. Run-time 
performance should be somewhere between the current HP3000 
interpreter and compiler. Special terminal drivers will be 
implemented for BCG BASIC to provide the 250 "personality". 


CONVERSION AIDS 


Utility programs will be developed which will attempt to 
automatically convert 125, 250 and 3000 BASIC programs and data 
files to BCG BASIC. A report will be generated detailing the 
changes made to the program. If the converter has problems or 
cannot translate certain constructs, the user will be asked for 
more information and/or the statement in question will be flagged 
for manual conversion. 


Our goal is to have at least 80% automatic conversion for current 
125, 250 and 3000 BASIC programs. This means that the users’ 
conversion effort will be no more than 20% of the effort required 
to rewrite the application. 


MPE IV 


by 
Mike Paivinen 
Computer Systems Division 
Hewlett-Packard Company 
19447 Pruneridge Avenue 
Cupertino, CA 95014 


This presentation will discuss the MPE changes in the kernel policy 

at a conceptual level. A general overview of the new feature set will be 
given. This presentation is basically aimed at those people who are 

just becoming familiar with MPE IV and will not be an in-depth 

technical presentation. 
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COMPUTER SYSTEMS DIVISION 
Accountina Systems Groun 
49447 Pruneridge Ave. 
Cupertino, Ca. SSO0iA 
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ACE: Operatorless Job Scheduling and Processing 
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ACE is an online tiob scheduling and processing onoplication. 
The application controls simultaneous processina aqueves of iobs 
ino a mubtivaachine network. A single master schedule controls the 
Qaveves and the machines on which execution will occur. 


ApDlving “scheduling parameters" to the master job List creates 


A month’?s schedule. The poraneters allow for scheduling o tob to 
executed by the day of the week, the workday of the month, or the 
nartiicular month of the vear, 


Paily orocessinga starts with assianing seauvence nunbers to 
the jobs scheduled for the dav and reviewing job dependencies. 
tach toh tis either scheduled to run or deferred for future 
precessing. the schedule is then executed in the established 
sequence with continuous orvgramnatic monitoring. Jobs are ontyu 
streaned upon successful completion of their dependencies. Mt the 
conclusion of the processing, a rapport is aenerated that lists 
successful. aborted. cancelled. and deferred iobs. 


The application has been prinarily desianed to be oaneratorless 
in its execution, thowever, a munval override capubility has been 
orovided. to changes in existing apolication prograns or JCL is 
reauired, 


Rackaround 


The Accowntinag Systems Groun of CSY reports to the CSY Controller 
and handles all accounting data processing for CSY. Our role within 
the Accounting Department is to support and davelon computerized ac~ 


counting svstems. 


In addition to support we have becone heavily involved and dedi-~ 


cated to} 


(1) testing new TP oroducts - both hardware and software, 
This includes not only doing nre-relense testina for 
functionality and reliability but also utilizing these 


products to develoo our distributed environment, 


(2) Fully utilizina HP software and hardware to implement a 
"distributed" data processing environment, i.e. one in 
which the cemouting power is where the peonle and 


problems are. This includes addregssinu the problens of 


System security and oneratorlessconnuters. 


We currently have our apnlicatsons spread across two HPS000 systems, a 
SERTES 44 and a SERIES 33. with a total of about 1000 Mb of disc 
Storage (Cfour of our disc drives are Private Volumes). One @6197A does 
the orinting for both machines (we use DS/3000 to coov snoolfiles from 
the Series 33 to the Series 44). We have one HIS macrocamputer in 
the department and are currently evaluating ar HIP3000 to be put in 
Accounts Pavable for dedicated processing. Our svstens group of fa 


professionals suvoports an accounting department of 40 pneonle. 


a) 


JOH PROCESSING FUNCTION 
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Job processing for batch jobs can be broken down 


i. 


ee 
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SCUEDULING. 


job 


that is on 


the Master 


Job List. 


into several tasks 


This consists of determining when to run each 


The Master Job List 


is the set of all batch jobs whose processing needs to be 


scheduled 


Along with th 


nmong jobs my 


jobs? 


conple tii: 


es 


(reasons 


e 


st 


of other 


for 


scheduling 


be 


jobs. 


taken into 


of 


If the 


jobs, 


orocessing will be "dependent" 


scheduling will be 


discussed). 


consideration. 


interdenendencies 


Certain 


voon the successful 


job stream that process~ 


Labor vouchers aborts, we would not want to begin the 


processing of our Labor Variance job stream until we suc 


cessfully <inish the Labor Vouchers. 


cludes 


tions 


PROCE. 


a. 


to 


comp 


nake 


of 


iob. 


SSING. This 


Streaming t 


identifying 


jobs that 


require 


Scheduling also in~ 


includes 2 interrelated tasks 


he 


jobs 


on the 


schedule. 


"extra considera- 


" cucy as tape mounts or private volume mounts. 


For the next job 


be orocessed, a check must be made for the successful 


letion of a11 iobs this job is dependent on, check to 


sure all extra considerations 


(private volumes , 


tanes, 


etc.), 


have been 


and then 


taken care 


stream the 


b. Monitor ng the processing of each job. Processing must 


be 


monat>cad 


50 


that 


when 


a 


job 


finishes 


or 


aborts, 


processing continues with either a restart of the aborted 
job or the streaming of the next available fob. 

REPURTING. AFter all orocessina is completed, the results 
must be recorded onto ithe master schedule and reported to 
the svsten users. In Data Processing it is necessary to 
inform the users as to what was accomplighed and to in 


form the svstems group of what oroblems muet be fixed. 


AUTOMATION OF THE JOR PROCESSING FUNCTION: ACE 


We have found that almost all of the job processina function can 
be automated. ACE is our applications subsvstem that handles ALL of our 
schedule processing for our Accountina denaptaens » ACE is an online 
job-scheduling and orocessing application. The anplication controls 
simultaneovs ovrocessing quveves of jobs in a multi-machine network. A 
Single master schedule controls the queves and the machines on which 
execution will occur. ACE is operatorless in its execution and 
reguires NO changes in existing application programs or JCL to inple- 
ment. The subsystem has two online programs, SCHEDULER and PROCESSOR, 


that are used to create and execute the job schedules. 


Taking the job processing function described above it will now be 
shewn how ACE is set vo and executed to process fobs. Flauvre 2.4 shows 


an overview of the implementation of the ACE subsvstem. 
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Figure 2.1 Implementing ACE 


ACE: THE MASTER JOB LIST 
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ACE begins with the creation of a MASTER JOB LIST. This list con- 
tains all the jobs ( on all the machines) that ACE will control. To 
create the list only two pieces of information are necessay, (1) the 
fullvy-qualified name of the file in which the JCL resides, which will 
be called the "JOB-NAHME”. and (2) the comouter on which the JCL usually 
resides. Optional information includes “DEPENDENCIES”. 


"EXTRA-CONSIDERATIONS". START~-~ TIME-STOP-TIME WINDOW. DEFAULT-QUEUE, 


AND DEFAULT-- SEQUENCE NUMBER, 


Dependencies are the job-names of those jobs upon whose successful 
completion the current iob depends. Extra considerations are denpenden- 
cies that ACE can’t handle. The application can check to see if the 
proper private volume is currently mounted, but it cannot physically 
mount the orivate volume itself. So the extra consideration is the 
reminder to the person setting up the dally schedule that "PRIVATE 
VOLUME AUDITO1 IS NEEDED FOR THIS JOB". Extra considerations are also 
commonly used to remind of needed tape mounts. The start-time-stop~time 
window allows a scheduled job to be run only between two svecified 
times, ie. the “window"’. If the window cannot be satisfied, the job is 
not streamed. The default aueve and default seavence number allow a 


one-time specification of these Items when their valves are fairly 


static. 


ACE: CREATING MONTHLY JOR SCHEDULES 
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Dnce the Master Job List has been snecified the monthly iob 
schedules can be created. To aid in the scheduling of tebs a set of 
“scheduling parameters” are defined within the suvstenm and can be used 


to create a schedule. 


In ovr Accounting department we nrocess Labor Vouchers avery 
Wednesday night. We orocess our first General Ledger to microfiche on 
the 3rd working~day of every month. We orocess some jobs every other 
week on Monday. some iobs everv dav of the week and some tobs only 
twice a year, What we have found is that most of ovr inobs have a dis- 
tinct pattern to thelr schedule, We’ve defined a set of naraneters 
that describe these patterns to aid us in our monthly scheduling. These 
parameters allow for scheduling 9 job to be executed by the day of the 
week, the workday of the month or the particular month of the vear. 
Using combinations of parameters any pattern can be described. There 
are also oarameters that allow for the exclusion of davs, weeks. or 


months. 


Once the parameters have been specified for each job, creating a 
specified month’s schedule consists of “applying” these parameters to 
the month’s calendar. The result is the actual schedule of the date 
each Job will run during that month, ACE maintains a table of holidays 
(inputted by the user) and will not schedule jobs on those specific 
dates. Once satisified with the schedule for the month, and when ap- 
orooriate (eg. the beginning of the month), the schedule is activated 


for use. 


ACE: DAILY JUL PROCESSING 


Yailv processino begins by entering SCHEDULER and requestina the 
dav’s schedule. ALL jobs scheduled for this dav, and ajl iebs from 
vrevious schedules that either aborted or were "deferred" will be 
presented. Only when ao iob finishes successfully or is cancelled is it 
reanoved from the current schedule, Seavence nunbers and aqueve numbers 
must be assigned to each itiob on the schedule. Denendencies are reviewed 
and are "denctivated” or additional added Lif desired. For tobs requir- 
ino orivate volumes or tapes, the private volume name or the logical 
device nunber on which the tape resides can be entered into the suysten. 
(PROCESSOR will then check to make sure the private volume is mounted 
before streaming a job and in the case of tanes will reoly to the first 
tape request). Each lob that anpnears on the schedule can either (4) be 
laft scheduled to run this duyv. (2) deferred for future processing. or 
(3) cancelled from the schedule. Deferred jobs will continue to anpear 
each following day until scheduled or cancelled. Cancelled jobs will 
not appear again until the next date they are scheduled to run, Jobs 
that were not scheduled may be added to the schedule at this tine as 
long as they exist on the Master Job List. For all iobs that are left 
on the schedule. MPE passwords are entered and the schedule is ready to 


process, 


The program PROCESSOR (Figure 3.1) executes the schedule. 
PROCESSOR is an online orogram that can be run from anv terminal on the 


susten. The orogram is executed in one of two modes: 


(4) AUTOMATIC RESUME mode in which PROCESSOR will execute the 
entire schedule without need of anv user interaction. 


Thas is the cure “onperatorless” mode. 


(2) MANUAL RESUME mode in which PROCESSOR wil execute the 
entire schedule by stopping after each inb is streaned 
and waiting for the user to let it stream its next sob. 
This mode is extremely useful when many ijiobs are denen 
dent ona sinole job. One can Jet the first jeb run ond 
then monitor the job to completion before Jettina 
PROCESSOR pick the next lob. Should the key job aobert tae | 
user could fix the oroblem and restart the job so it 
finishes successfully. This way the jobs depending on ite 


completion wovld be streamed instead of being deferred 


because thelr denendencies couldn’t be met, 


The program allows the user to switch between automatic resume and 
manual resume at any time by using control-Y. The user could monitor 
that first kev job using manual resume and voon its successful com ule- 


tion leave PROCESSOR in avtomatic-resume and go home, 


PROCESSOR picks the next jiob to strenm according to a straiaht- 


forward set of rules. 


(4) Only one iob from a particular queve can be in processing 
at any time. Until the outcome of the current job is 


resolved. all following jobs in that queve wait, 


(2) Each aveve 1s processed in the order of the sequence 


numbers assianed to each job. No job will be considered 


10 


for processing until a11 jobs ahead of it have teen 
processed (this means either finished successfully. 


aborted or deferred because dependencies weren’t met?) 


(3) PROCESSOR will continually loon seauentiaily through the 
aqueves checking to see if the next job in each queue is 
ready to stream or must be deferred hnecause of Gerencency 
aborts. PROCESSOR can have as many jobs orocessing 45 
there are aveves active for the schedule Cat can’? ie 
more be cause of rule (1) and it could be less beacause 


dependencies can cross queves forcing oné Queve to wadt 


until another’s job finishes). 
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x x x x 
ROO IORI OK OOIOKOK KKK KK ROO OOO OK OOO IG IO 
KRUN SCHEDULEX *LIST SCHEDULEX ¥CHANGE SCHEDULE¥ ¥*RUN SYS UTIL 
FOO OIRO IOI IO IORI K SOOO OOOO JOO RIOR OK KOK KK 
XAUTOMATIC KLIST SCHEDULE XSUSPERD A QUEUE KSTREAM A JOR 
RESUME ONLINE/OFFLINE XDELETE A QUEUE KARUN TO 
XMANUAL KLIST A QUEVE KXADD,. DELETE. OQ8 XUN SPOOK 
RESUME ONLINE/OFFLINE MODIFY A JOB ¥EXECUTE AN 
XLIST A JOR. MPE COMMANT 
ONLINE /OFFLINE 
*’> SHOW’? COMMANDS 
SHOWJOB JOB=CJ 
SHOW JOB 
SHOWOUT JOR=@ 
SHOWOUT JOB=e! 
SHOWOUT JOBR=@:READY.N 
Figure 3.1 PROCESSOR. 
Hesides beina able to specify which mode to run the schedule in. 


there are other tasks which can be performed from PROCESSOR. 
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First, there are a whole set of “LEST” commanas for reviawing 
scheduled and running iobs. Jobs, auveves, or the entire schedule can be 
Listed either online or offline. Figures 3.2 and 3.3 show the format 


of the schedule lists. 


Second, the schedule can be altered from withan PROCESSOR, Gueves 
can be deferred, cancelied, or suspended. Jets can be added. modified 
or deleted. When modifying jobs, dependencies can be added or 


deactivated. 


Third. PROCESSOR uses orocess handling t9 qllow the user to stream 


aq iob, run TDP.PUR.SYS. run SPOOQK PUR. SYS. or execute other STE com 
mands. This is to allow for -restartina aborted jobs from Within 
PROCESSOR. SPOOK is used to read snpoolfiles. TDP af an editor. and the 
stream command not only streams the iob but also Sets uo the Jah 


streamed as an ACE job. 
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R 


Cc 


JOB~NAME 


JOBi4.GROUP , ACCOUNT 


JORI2, GROUP .ACCOURT 


DEPENDENCIES 
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When PROCESSOR finishes orocessing the production schedule the 


last job streamed generates a report summarizing the results of the 
processing. Aborted jobs, deferred jobs, cancelled jobs, and successfua 


~” 


igbs are all reported in this report. We then pest this report for the 


YSers. 


An Introduction to CCITT Recommendation X.21 


Bill Baddelev 
Hewlett Packard 
Commercial Svstems Pinewocd 


This paper is an introduction to CCITT Recommendation X.21. The 
recommendation specifies a new data communications interface 
which you will probably encounter soon if vou haven't already. 


At the present time, most data communications among remote 
terminals and computer systems are carried over the public 
switched telephone network or over leased telephone circuits. 
The telephone network has evolved over many years and is an 
excellent medium for voice transmission. When people started 
connecting computers and terminals over long distances, the 
telephone network provided a readily availble, though not an 
optimal, connection medium for digital signalling. Computer 
systems and terminal equipment are tvpicallv connected to the 
public switched telephone network or leased telephone lines 
through an interface which is referred to by the label RS-232 or 
v.24. This interface type has been around for quite some time 
and is commonly available on modem and terminal equipment. 


An organization of devoted to international cooperation in 
telecommunications, the CCITT, is an international advisory body 
which deals with telephone and telegraph communications. The 
CCITT issues recommendations for services and implementation of 
services. There is a series of CCITT recommendations (the 
"V-series" recommendations) for the connection of data terminal 
equipment or DTE (the category DTF includes terminals and 
computer systems) to the telephone network through a modem. The 
connection point to the telephone network is called the data 
circuit terminating equipment, or DCF. The standard connection 
between terminals or svstems and-the telephone network is 
described in CCITT recommendation V.24 and the FIA (the U.S. 
Flectronic Industry Association) RS-232. The 25=-pin connector 
which vou mav have seen on vour terminal cable or computer system 
is the standard connector for this interface. The V.24 or RS232 
connection carries signals between the terminal or computer and 
the modem. These signals include the transmitted and received 
data signals, timing information and control signals which 
constitute a dialog between the modem and the computer concerning 
the state of the connection. For leased telephone circuits, the 
V.24/RS-232 connection carries all of the information needed 
between the modem and the system or terminal. The V.24 
recommendation specifies the function of each of the data and 
control circuits in the interface, and the dialog between the 
terminal/svstem and the modem/DCF. For switched telephone 
connections, some PTTs offer automatic calling units. cCTTT 


recommendation V.24 also describes the standard interface between 
a svstem or terminal: and the automatic calling unit (the FIA 
specification is RS-366). This interface uses the same 25-pin 
connector as the V.24 modem interface with redefined signal 
lines. The V.24 recommendation specifies the dialog between the 
svstem/terminal and the automatic calling unit for. establishing 
connections. 


The telephone network is being replaced for some classes of data 
communications traffic by public data networks. There is a lot 
of information in the computer press these davs about the new 
public data networks and the new international standards for 
these data networks. Depending on where vou are located, vou may 
have heard of either X.25 or X.21 or both. The CCITT has issued 
a series of recommendations (the X series) which deal with data 
communications networks. The X series of recommendations deal 
with services on networks which are specifically designed for 
data communications. There are quite a few public data networks 
now in operation, and more services are planned for introduction 
within the next few vears. 


These networks can be broken into two principal categories 
according to the tvpe of service which thev offer. One tvpe is 
Circuit-Switched, where the connection between two svstems or 
terminals is‘ equivalent to a hardwired connection once it has 
been established through the network. Fxamples of circuit 
switched networks are the Nordic Public Data Network in Denmark, 
Finland, Norway and Sweden and the DATEX-L network in the Federal 
Republic of Germany. The other type of network is 
Packet-Switched. Packet switched networks support multiple 
virtual connections through the network over a single DTE/DCEF 
connection. 


The CCITT X.21 recommendation describes an interface between Data 
Terminal Fquipment (terminals and systems) and Data 
Circuit-terminating Fquipment for synchronous operation on public 
data networks. This interface replaces the two-connector, 
multiple signal interface of V.24 with a simpler set of signals, 
a smaller connector, and improved electrical characteristics 
(fig. 1). 


Comparison of CCITT Recommendations V.24 ard X.21 The X.21 interface is better able to meet the requirements of 
See current svstems for data communications than is V.24 in terms of 
speed and distance between the svstem and the network port 
interface. The speeds of service in public data networks under 
the CCITT X recommendations are easilv met bv the X.21 interface, 
V.24 X.21 the fastest being 48 kbits/sec. For this reason, X.21 is 
graduallv replacing the V.24 interface. 


The CCITT X.25 recommendation, which covers packet-switched data 
networks, specifies the X.21 interface as the electrical and 
mechanical interface between the DTF and DCF. The X.25 

DTF pce | recommendation will be covered in more detail later in this 
session. 





Auto Call 
Unit. 


In addition to the electrical ard logical definiticr of the X.21 
interface, the CCITT recommendation describes logical procedures 
for the operation of the interface in a circuit-switched network 
Distance: ¢< 20 Metres > 1000 Metres and in leased-circuit applications. 


Speed: ¢< 20 Kbit/sec. > 100 Kbit/sec. The circuit-switched network procedures are broken into feur 
phases: the quiescent phase, when no connection exists between 
the local station and anv remote station; the call establishment 
phase, when either the DTF starts 3 call or the DCF signals an 


Signals: <= 31 signals <= 7 signals inceming call; the data transfer phase, and; the call clearing 
phase. The circuit-switched network procedures are verv much 
Connectors: 1-2 25-pin 1 15=pin like the procedures one uses with the switched telephone network. 


During the quiescent phase, the telephone is on-hook. Tn the 
X.21 case, the svstem/terminal and the network signal their 
respective states of readiness tec establish a cennection through 
the network. 


The call establishment phase, in the case of the telephone 
conversation, begins wren one lifts the receiver and dials a 
number or when the telephone rings, signalling an incoming call. 
In the X.21 network, the terminal/svstem signals to the DCF that 
it is preparing to issue selection signals; the DCF responds bv 
Signalling "proceed to select", and then the DTF issues a 
selection signal sequence specifving a remote station and/or 
network services. An incoming call is announced bv the DCF to 
the DTE/svstem/terminal. All cases of call collision (ircoming 
and outgoing calls at the same time) are resolved in favor of the 
outgoing call. If one dials a busv station or mis-dial a number, 
vou receive in response a tone or tone sequence, or perhaps a 
recorded message. In the case of an X.21 network, the calling 
DTF receives call progress signals (figure) which indicate whv a 
call is delaved or whv it has failed. These call progress 
signals are useful in determining a reasonable next action. Tn 
additon to call progress signals, the X.21 recommendation 
describes optional facilities for transferring information such 
as called line identification to the calling DTF and calling line 
identificaiton toe the called DTF as part cf the call setup 
procedure. 
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X.21 Call Progress Signals 


Meaning 


Terminal Called 
Redirected Call 
Connect When Free 


No Connection 

Number Busv 

Selection Signals Procedure Frror 
Selection Signals Transmission Frror 


Access Barred 

Changed Number 

Not Obtainable 

Out Of Order 

Controlled Not Readv 
Uncontrolled Not Readv 

DCE Power Off 

Invalid Facilitv Request 
Network Fault in Local Loop 
Call Information Service 
Incompatible User Class of Service 


Network Congestion (short term) 
Long-term Network Congestion 
Registration/Cancellation Confirmed 


Redirection Activated 
Redirection Deactivated 


signals are delav conditions without call clearing 
Signals indicate short-term conditions 

and 5 signals indicate long-term conditions 

signals are short-term network related conditions 
signals are long-term network related conditions 
Signals are confirmation signals (with call clearing) 


Once the call setup is complete, the connection between the 
calling and the called DTFs is transparent. The network 
transfers the states of each station's transmit data line 
bit-for-bit exactlv as it appears at the DCF interface. The data 
phase continues until one of the DTFs signals a clear request. 
This is analogous to the conversation part of a telephone call. 


Call clearing is signalled by either end and transferred to the 
opposite end. Following call clearing, the DTF and DCE re-enter 
the quiescent phase. 


The circuit switched public data network has several advantages 
over the public telephone network, having been designed expressly 
for data communications. One clear advantage is automatic call 
establishment (no operator dialling). 


The X=-series recommendations include recommendations for a 
uniform international node numbering scheme which is analogous to 
the international telephone numbering scheme. For example, each 
Nordic network connection has a 6-digit network number, which is 
unique within the country. International calls include an 
international prefix, a network/nation code, and a network node 
identification number. Within the Nordic Public Data Network, 
calls are possible among the nations of Denmark, Finland, Norway 
and Sweden. 


Another feature of the new public data networks is fast call 
establishment and high reliability. For example, the Nordic 
Public Data Network specifications state that all calls will be 
set up within 2 seconds, 99% will be set up within (.5 seconds 
and 90% of all calls will be set up within 0.1 seconds. 
Similarly all call clearing operations will take under 0.2 
seconds, with 90% under 0.05 seconds. This is clearly an 
improvement over the performance of the switched telephone 
network. 


The X.21 call progress signals, described previously, provide a 
clear indication of the status of a given call attempt along with 
information about the probable success of a retrv. 


Additional facilities allow the subscriber to simplify the call 
process by using short-form addresses for commonly called remote 
nodes. Access restrictions can be placed on a given node bv 
specifving optional facilities to bar incoming or outgoing calls. 
A group number facility allows several ports to be accessed from 
the network by a common node address; a central computer can be 
equipped with several ports which, in addition to their unique 
addresses are also accessed via a common national/network number. 
This facilitv is also referred to as "multiple lines at the same 
address". The Closed User Group facility allows the creation of 
private networks within the larger public data network. If a 
company has several svstems at different geographical locations, 
and has no need to connect them to svstems outside of the 
particular set, then the specification of closed user group 


membership for each of them eliminates access from computers 
outside the network. The facility can also be used in such a way 
as to restrict the connections from anv node in the group to onlv 
other group members. It is also possible for a particular node 
to belong to several closed user groups, one of which is the 
default or preferential one. In order to switch from the 
preferential to an alternate closed user group, the selection 
signal sequence is prefixed with a facility request code 
specifving which alternate group is to be used for the call 
setup, followed bv the address of the node within that group. 


A call queueing facilitv allows incoming calls to be held in a 
first in first out queve with a specified number of positions. 
The caller receives a cell progress signal indicating that the 
call is queued at the remote end. The call redirection facilitv 
allows one node to temporarily transfer its address to another 
node; for the period during which this facilitv is activated, all 
calls for the node are redirected automatically to the alternate 
node. A call progress signal informs callers that the call has 
been redirected. The Calling and Called Line identification 
facilities provide for verification and monitoring of connections 
made through the network. A node specifving the Charge Transfer 
facilitv is charged for all incoming calls (which are normally 
charged to the caller). The charge advice facility allows a node 
to be informed, following disconnection, of the charges for a 
call. 


Circuit-switched X.21 networks are currently offered in Denmark, 
Finland, Norwav, Sweden, F.R. Germany, and Japan. Several other 
Furopean nations have X.21 networks in their future plans. 
Further information about the specification and the network 
services is available from the implementing PTTs, and from the 
CCITT (Union Internationale Des Telecommunications, Place des 
Nations, CH-1211 GENFVF 20, SUISSF). 


Design Considerations for Support X.25 
Communicator Networks 


by 


Shnider Youssef-Digaleh 
Hewlett-Packard Company 
Information Networks Division 
19447 Pruneridge Avenue 
Cupertino, CA 95014 


Over the past decade Data Communications has been revolutionized by a 
radically new technology called Packet Switching. Ccitt Standards have 
been defined and adopted in a timely fashion as a solution to the 

urgent need for an agreed upon protocal. This has the advantage that Ccitt 
Standards are widely applicable and are not limited to a specific 
manufacturer or vendor defined protocol. 


Hewlett-Packard has initiated a major commitment to the use of 
internationally accepted standards protocols as the fundamental basis for 
its Hewlett-Packard distributed System Network Communication Architecture. 


Terminals Strategy and new products 


by 
Richard Franklin 
Grenoble Terminals Division 
Hewlett Packard Company 


Since the first HP terminal 2640A was introduced in November 1974, 
HP has constantly been making head lines thanks to its terminals 
features, reliability and contributions. 


With 11 terminals, HP has a very wide range of terminals available 
today to fit any user needs in the five application areas onto 
which HP is concentrating. 

- Data entry 

- Program preparation 

- Text preparation 

- Data analysis 

- Cad/Cam 


Data analysis, mainly thanks to the HP3000 success, is by far the 
application where our terminals have been sold. 


Today we introduce a new terminal, the 2382A office display terminal 
which offers features such as: 


- 9'' display 
2640/2622A compatibily 
- 2 full pages of memory 


- 8 screen labeled softkeys 
With its compact design, this unique device can fit on top of any desk. 


The 2624B is also new in this area. It offers all the 2624A features plus 
multipoint, local forms cache, printer pass through and record mode. 


For the ever growing data analysis application, HP presents today the 
2623A graphics terminal with its block mode capability, 2 full pages of 
memory, user definable soft keys, national character sets, its 512 x 

390 dots resolution, and DSG/3000 support, the 2623A provides a low lost 
graphics solution. 


But not only HP works on designing new terminals but also on providing new 
software tools for existing products. For example 4 new software packages 
are now availabel on the 2647A. 


INTERACTIVE HP-3000 TO IBM HOST COMMUNICATIONS 
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INTERACTIVE HP 3000 TO IBM HOST COMMUNICATIONS 


INTRODUCTION 


Interactive Mainframe Facility (IMF), previously known as 
Interactive Mainframe Link, has been enhanced with new features 
and improvements on existing features. The purpose of this paper 
is to introduce DSN/IMF to new users as well as inform current 
users of the improvements and new features. 


OVERVIEW 


IMF is a product that enables an HP 3000 Computer System to 
emulate a remote IBM 3270 series Cluster Control Unit. In pre- 
vious releases, IMF only supported Binary Synchronous Communica- 
tions (BSC). Now IMF also supports 3271 Synchronous Data Link 
Control (SDLC) as an SNA physcial unit type one. Through IMF, 
users on an HP 3000 can send data to and receive data from appli- 
cations on a remote host. A user can access a remote host appli- 
cation either programmatically through IMF Intrinsics or inter- 
actively through IMF's Pass Thru Facility. 


It is possible to use IMF for data entry and retrieval to a 
remote host application. These host programs issue write com- 
mands which send screens of data to remote terminals and _ read 
commands which receive data from remote terminals. The host reg- 
vlates data transmission, therefore IMF sends and receives data 
when the host instructs it to do so. 


In order to establish communications with a host system, the 
HP 3000 uses an interface called an Intelligent Network Proc- 
essor. The INP handles the line protocol and performs many 3270 
controller functions. The INP software communicates to the HP 
3000 software through HP's internal Communication Subsystem (CS). 
IMF and the INP together appear to the host like a 3270 Control 
Unit. 


There are four major components in the IMF product. They 
are the INP, the IMF Intrinsics, Pass Through Mode, and the IMF 
Manager Program. To understand the product, a user needs to know 
what these components do and ‘ow they interact. These components 
and their interaction are briefly described below. 
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IMF provides Intrinsics which users can call from COBOL, 
FORTRAN, SPL, or BASIC. In most cases, the intrinsics allow a 
user to tailor his HP 3000 program to fit an existing IBM appli- 
cation, The Intrinsics are easy to use, and they perform func- 
tions which include transmitting data, receiving data, reading a 
Screen of data, and locating the 3270 field attribute bytes in a 
Screen of data. An HP 3000 application using the IMF intrinsics 
appears aS an interactive session to an IBM Host. 


IMF also provides a Pass Thru Facility, previously called 
the Inquiry and Development Facility, which allows most HP ter-— 
minals and printers to interact with a host application without 
additional programming on the HP 3000. When using the Pass Thru 
Facility, HP terminals and printers function as 3270 terminals 
and printers. 


The IMF communications line is controlled by its Manager 
Program, From within this program, a user with OP (System Super- 
visor) capability can issue commands such as START and STOP to 
control the IMF subsystem. The Console Operator may also issue 
commands to control the subsystem, 


IMF requires a configuration file for each IMF 
communications line in operation. This file contains information 
about the line such as the logical device number of the INP, the 
control unit number, and a list of the devices configured on the 
host system. The configuration file also contains a list of 
users that are allowed to use the communications line. The IMF 
manager may override the allowed list of users in the configur- 
ation file. 


ENHANCEMENTS 


As mentioned in the overview, IMF now @ives the user the 
option of using either 3271 Synchronous Data Link Control (SDLC) 
as an SNA physical unit type one or Binary Synchronous Communica-— 
tions (BSC), There are many advantages in using SDLC protocol. 
SDLC provides better data security because it does more hand- 
Shaking than BSE protocol. Although BSC lines can be supported 
in an SNA network, IMF support, of SDLC eliminates the need and 
overhead to maintain BSC lines. SDLC protocol allows different 
types of SNA devices and systems to use the same multidrop line. 
Multidrop lines can use higher Speeds with SDLC protocol than BSC 
protocol, 
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IMF now supports IBM's Conversational Monitor System (CMS). 
This is an important enhancement since CMS and IBM's Virtual 
Machine 370 (VM) are widely used. 


The first release of IMF had a restriction on the size of a 
data block that could be received from the host application, 
This restriction has been removed in the second release for both 
protocols. A segmentation scheme has been implemented in the BSC 
driver to segment the incoming host data into 256 byte blocks for 
processing, and the SDLC protocol sends 256 bytes of data in one 
frame. 


IMF's design has changed to solve two character code 
problems encountered in the first version. First, the ASCII to 
EBCDIC translation function has been moved from the INP to the 
3000 and now uses MPE's CTRANSLATE Intrinsic. Therefore, users 
who have special character translations will see those transla- 
tions in their IMF applications as in all other Data Communi ca- 
tions products. Second, eight-bit character codes like Katakana 
will be easily supportable in the new version. Eight-bit cher- 
acter code support is now possible because IMF no longer uses the 
high order bit to denote a 3270 field attribute byte, 


The receive timer for the RECV3270 Intrinsic has been 
expanded to cover the TRAN3270 Intrinsic so that a user may 
detect that the host has stopped communicating without needing to 
use no-wait I/0. 


The IMF monitor now identifies the communications line 
number in its messages. This is essential for installations 
where more than one IMF line is in use at once. 


The IMF Manager's DISPLAY ALL command has been improved. A 
message has been added to indicate whether the host is communica-— 
ting or not. Also, if CS Trace is running the name of the cur- 
rently opened trace file is displayed. 


The default name on a CSTRACE file name has been changed to 
IMFTRXXX.PUB.SYS where XXX is the ldev of the pseudo-device. 


When the Pass Thru Facility is terminated on a 2640B 
terminal, it will print a reminder message on the screen to un- 
latch the block mode key. 


A new Intrinsic, PRINT3270, has been added to IMF, This In- 
trinsic will enable the user to get a hardcopy snapshot of his 
Screen image. The screen can be printed in two different for- 
mats. One format shows attribute characters and nulls and is 
very useful for debug purposes. The other format prints. the 
Screen as it would be viewed on a terminal and thus provides some 
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of the features of a local copy. A user interface to this 
Intrinsic will allow it to be called from the Pass Thru Facility. 


There has been a change to the IMF philosophy when the host 
stops communicating. Basically, the IMF Subsystem will remain 
active if the host stops communicating and will not have to be 
restarted when the host starts communicating again. Pass Thru 
terminals, however, will exit the Pass Thru Facility and return 
to MPE. Users might have to re-establish their sessions with the 
host since IMF cannot maintain them on the host side, Dur ing 
the time that the host is down, any TRANS3270 or RECV3270 intrin- 
Sic calls will receive an error message stating that the host is 
not communicating. It is important to remember that IMF cannot 
distinguish when a host subsystem or application terminates if 
the access method continues to send control sequences through the 
phone line. 


A data stream mode has been added to IMF to provide a means 
of file transfer between the host and the 3000. This mode will 
@llow an application program to obtain the untranslated data 
Stream from the host. This mode is only allowed when using SDLC 
protocol, Two new intrinsics, READSTREAM and WRITESTREAM, have 
been added for using this mode. The data stream is kept in the 
same format as the host sent it in and no screen image is pro~ 
duced. Hence, a user in data stream mode is not allowed to use 
any of the IMF Intrinsics which access an internal screen image. 
Likewise, a user who is not in data stream mode may not access 
the READSTREAM and WRITESTREAM Intrinsics as the data stream is 
not maintained, 


CONCLUSION 


For HP 3000 users who need to access data on a . remote IBM 
mainframe, IMF is an excellent solution. In addition to 3270 
emulation, IMF enables users to write HP 3000 applice-ions that 
can communicate with host applicatic:s. The new functions and 
enhanced features provide increased functionality and extend 
IMF's useability in SNA host environments. 
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I. INTRODUCTION 


The market for business computer graphics products is expected to 
grow at 59% per year over the next five years. In part, this 

growth is a result of the increasing interest in managerial pro- 
ductivity and the realization that computer generated graphics is 
a tool that can be employed today to improve the effectiveness of 


management decision making. 


Functional managers and professionals in finance, marketing, man- 
ufacturing, personnel and accounting are seeking better ways of 
defining and analyzing problems as well as communicating their 
findings to other decision makers. These managers are looking to 
their data processing departments for advice and recommendations 
on how to develop computer graphics systems. Data Processing . 
managers will play a very important role in improving managerial 


productivity in the future. 


This paper will describe some of the historical trends in Office 
Productivity, and then explore the role of management in todays 
organizations. Emphasis will be placed on how graphics can help 
managers in the decision making process. The conclusion also 
offers a brief discussion of the implications and opportunities 


that these trends have for data processing professionals. 


II. A HISTORICAL PERSPECTIVE OF OFFICE PRODUCTIVITY 


In this century enormous strides have been made in increasing the 
productivity of industry and agriculture. Technological innova- 
tions have greatly improved not only output per capita, but also 
the standard of living. Until relatively recently however, very 
little attention has been given to office productivity. This 
lack of concern is very apparent in the low capital investments 
and low productivity improvements made in the office in the last 


decade for the average worker in the United States. 


Capital Investment Productivity Gains[1] 


Office Worker  $ 2,000 4g 
Industrial Worker $25,000 90% 
Farm Worker $35,000 185% 


At the same time, it is interesting to note some of the other 
trends that are taking place in business organizations and 


specifically in the office: 


o In the United States, over 240 billion pages of computer 
printout was created in 1980, up 25% over 1979.[2] 


o Office workers are becoming a larger percentage of the 


total labor force as the U.S. becomes more of a service 


oriented economy from 22% in 1980 to 30% in 1990.[3] 


o Electronics and memory costs are dropping between 20% 
and 40% per year, while labor costs are rising at 


74.01) 


© The total cost of producing a letter in the United 
States is estimated at $6.63.[4] 


These facts all bear witness to what has’ commonly become called 
"The Information Explosion". As Alvin Toffler, the well known . 
futurist points out in his book, The Third Wave, we have tried to 
automate our offices the way we automate factories in a 
routinized manner that increases the quantity of output but note 
necessarily the quality. This approach has not yielded commensu- 


rate productivity gains. More data is not always better. 


The advent of electronic word processors is evidence of the 
economic incentives to automate the office. It is clear that 
there is vast room for improving the manner in which we handle 
Gocuments. Time savings may be quantified and document creation 
costs reduced. What is not so measurable however, is management 
productivity. How does One measure a manager's productivity? 

The number of decisions made? The quanity of memos written? The 
length of meetings attended? Clearly these are not very good 
measures. And yet, when examining office productivity one 
needs to put secretarial and clerical vs. managerial and profes- 


sional productivity in perspective. 


o 75% of the $640 billion spent on direct labor costs in 
U.S. offices goes towards management and professional 


Salaries and benefits. [5] 


o 80% of one U.S. insurance company's office costs went 


toward management and professional salaries.[1] 


One needs to ask, why we are not looking more closely at improve 


ing managerial productivity . In fact, this process has begun. 


The result has been a high degree of interest in tools to make 
managers more efficient and more effective: electronic mail, 
teleconferencing, decision support tools and graphics. Before 
exploring managerial productivity further one needs to define 
exactly what is meant by management and what managers do in the 


decision making process. 


III. WHAT IS MANAGEMENT? 


What type of information do managers need? 


Managing means many things to many people. In fact, there are 


ve) 
probably as many definitions of management as there are manage- 
ment styles. In any case, several key ingredients invariably ap- 
pear in a description of management: 
oO Planning, organizing and controlling 
re) 
-key elements in management. 
fe) "Getting things done through other people" 
-clearly communicating goals, providing incentives to 
motivate employees and delegating responsibility 
fe) 
re) Making Decisions 
-one of the main purposes of managers is to take 
relevant information and determine the best course of 
action or allocation of resources to maximize or 
minimize occurences that conform to their organizations re) 
objectives. 
From these definitions of management, one observation fis very 
clear. If managers and business professionals primary function 
is decision making, then information is their most important 
resource. Note the distinction between data and information. 
There is an excessive amount of untimely and irrelevant data 
available to most managers today which explains the reason so re) 


many computer printouts go unread. Information on the other hand 





may be a summary of only the most important elements that affect 


@ managers sphere of influence. 


Relevant information 
- unrelated data will only be time-consuming and 


distracting 


Timely information 


- obsolete data in todays competitive environment is usually 


worthless information 


Accurate information 
- unreliable data may mislead a decision maker; however, 
spending excessive time accumulating and verifying it may 


make it untimely. 


Summarized information 

- although some levels of decsion makers need details, most 
managers need to see the "big picture". Managers can ill 
afford to spend time reading about an operation or divi- 
sion that only affects 1 or 2% of their sales, profits, 


costs, etc. 


Well formatted information 
- nothing is worse than pertinent information that is bur- 
ied in long listings of hundreds or even thousands of vari 


ables. Key facts, trends and relationships should stand 


out so that managers can quickly grasp their meaning and 


proceed in their analysis. 


With these information needs in mind, it is very interesting to 


observe how managers really do spend their time on a day to day 


basis. 


IV. HOW CAN GRAPHICS HELP MANAGERS SPEND TIME MORE EFECTIVELY? 


Many theories have been postulated and estimates made of how man- 
agers spend their time. There have even been a number of profes- 
Sional studies. One of the most comprehensive surveys was con- 
ducted by recording the activities of 300 managers and pro- 
fesionals in 15 organizations every 20 minutes throughout their 


working day. [6] The results were very revealing: 


MANAGERIAL.ACTIVITY PROFILE 





This vividly illustrates the role of meetings in the management 
process. Being able to convey information succinctly as well as 
understanding the presentations of others is essential for suc- 
cess. Any significant contribution to managerial productivity 
must address this communication intensive joint decision-making 


process. 


Meetings 


Electronic mail may reduce the need for some meetings and tele- 
conferencing may reduce the travel time and expense of others, 
but graphics can make meetings more effective. Using visual aids 


such as charts and graphs: 


fe) Ideas can be conveyed more rapidly using colors and tex- 
tures in a visual format -- reducing meeting time. It is 
interesting to note that 35% of managers thought meetings 


were too long and 34% thought they were unproductive[6) 


e) Information can be displayed in a more interesting format 


-- keeping the attention of participants 


fo) Concepts are more easily retained by listeners because hu- 
mans are more accustomed to storing visual images. This 
improves the results of the meeting. For a physiological 
explanation of why graphs and visual images are more easily 


retained by the human brain see [7]. 


The most relevant data can be presented in a summarized 
format -- focusing attention on the key points of 


discussion. 


Document Creation 

Document creation which consumes 13% of the average manager's 
time consists of composing, creating, editing, designing, and 
drawing documents. This activity has enjoyed some productivity 
improvements with the advent of less expensive dictation equip- 
ment and word processing. Graphics can also make a contribution 
in this activity by providing managers with the tools to more 
effectively communicate their ideas and influence other decision 
makers. In realization of this fact, the Harvard Business School 


recently created a new course on the use of business graphs. 


Reading 


Reading which accounts for 8% of managers and professionals time 
would benefit greatly if document creators used graphics since 
readers would be able to more quickly grasp key ideas. ‘In fact, 
the analysis of [7] indicates that the Human brain is able to 
absorb between 48 and 72 million words per minute in visual im- 
ages vs about 600 to 1200 words per minute for the average 


reader. 


Aside from these activities, professionals and managers spend 
about 25% of their time on less productive activities that should 
frequently be performed by support personnel: filing, copying, 


seeking information, seeing people, scheduling, organizing work, 


waiting, etc. Electronic filing, electronic mail, and intelli- 
gent copiers will help to improve productivity in this area in 
the future. Traditional business display graphics are not very 
relevant to these activities although some software packages will 
provide capabilities to create organizational charts, Gant 
charts, and Program Evaluation and Review Techniue charts, 
(PERT). Some professionals will use these specialized tools, 
quite frequently but support personnel will probably prepare 


these charts ‘because of their routinized nature. 


The last activity which takes up an average of 8% of a managers 
time is analysis. This is probably the one activity that people 
most closely associate with managing and decision making. Before 
discussing the very important role of Graphics in analysis and 


the decision making process one last point needs to be made. 


Management Styles are different just as managers’ jobs vary from 
one organization to another. The amount of time spent on dif- 
ferent activities varies from one Manager to the next. In the 
chart below, it is apparent that professionals and lower level 
managers spend more time on less productive tasks probably be- 
cause they do not have Supporting staffs. It is also clear that 
they spend more time doing analysis and document preparation than 
upper level managers. At the same time, senior Managers spend 


considerably more time in meetings. 





From these observations a picture begins to emerge of lower level 
managers collecting and analyzing data, generating solutions and 
communicating these solutions to upper level Managers who review 
them. It also brings up the question of the type of data that is 


desired by different managers. 


Typically lower level Managers deal with data internal to the 
organization (orders, shipments, inventories, etc.) while senior 
level managers deal with both internal and external data (infla- 
tion rates, interest rates, industry growth, etc.). These lower 
level managers and professionals may need graphs produced from 
data resident on an existing data base while senior managers may 


want to use their own data. 


In fact, Computerworld magazine estimated that "top managers 
spend less than 2% or 3% of their time dealing with computer 


printouts, terminals, or intelligent stations".[8] 


This has important ramifications for the decision making process 


as we will see in the next section. 


V. HOW DOES GRAPHICS HELP MANAGERS MAKE BETTER DECISIONS? 


With this basic understanding of how Managers spend their time 
and the ways graphics can make them more productive, it is in- 
structive to look even more closely at how an individual manager 
might go through the decision making process. Specifically, I 
will use Hewlett-Packard's Decision Support Graphics/3000 as an 
example of a powerful computer graphics package that can help 


Managers make: better decisions. 


Although there are a multitude of ways to make decisions ranging 
from the basic scientific method to sophisticated operations 
research models, there are usually several steps that are common 
to all techniques. The schematic below illustrates some of the 


main steps in any decision making process. 


Figure 3 
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Problem Definition: Before launching into any type of analysis, 


the decision maker needs a clear understanding of the problem at 


hand, perhaps even further defining it. In some cases, objec- 
tives need to be set and assumptions stated. In others, the 
decision maker may need to question the basic premise of whether 


a problem even exists or what the decision criteria are. 


A good example of how a graph can help define a problem is shown 
below. A manager looking at this sales data might be very con- 
cerned about the decline in sales. However, by displaying last 
years data next to this years, it is apparent that there may not 
even be a problem, rather, sales are seasonal and one can expect 


a decline during certain months. 


Figure 4 
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The next example shows sales of a product ouee-weveral years. By 
looking at a column of numbers, it might be obvious that sales 
have been growing. In the graph below however, something else 
emerges: Sales grew at a rapid pace the first three years but 


have almost leveled off in the last year. 


Figure 5 


SALES GROWTH 





Data Collection: Once the problem is defined, the decision maker 
can proceed to gather data that is relevant to the decision. 

This data may reside in file cabinets, in reports, with other 
people or hopefully, in a computer data base where it can be 


quickly retrieved. 


DSG/3000 was specifically designed with data retrieval in mind. 
If data originates from a managers own information base (external 
to the organization), this information can be entered quickly by 
filling in a menu. If the data is in an IMAGE data base, Query 
may be used to retrieve the data for a graph. Other tabular MPE 
files may also be used. Below is an example showing how data can 


be entered in the DSG/3000 data prompt menu. 


Figure 6 





Thus, DSG/3000 is ideal for periodic reporting where the same 
chart is used month after month since it can be updated automati- 
cally with the most recent data. At the same time, however, cus- 
tomized graphs can be created with manually entered data for spe- 
cial presentations. This flexibility is important to consider 
when designing a graphics system. Since senior managers often 
deal with external data that is not resident in the organiza- 


tion's information systems. 


Analysis: With the appropriate data in hand, the decision maker 
can proceed to determine what is relevant, how accurate it is, 
and then begin analysis. Frequently, this is the longest step in 
the process because the data must be prepared and formatted so it 
bene manipulated. Most business managers and professionals 


then perform some combination of the following analyses: 


oO extrapolating trends over time 

fe) Studying relationships between variables 
oO making Eomparieens between entities 

fe) looking for exceptions and variances 


These four types of analyses lend themselves to visual portrayal. 
Trends as we saw in the example of sales over time are usually 
displayed in a line chart or a series of bars in a bar chart as 


shown below. 


Figure 7 
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Relationships can also be displayed in line charts like the pre- 
vious example where we saw the relationship of sales in the dif- 
ferent periods. Clustered bar charts like the example above 
vividly show the relationships of two variables over time. Pie 
charts like the one below are ideal for comparing the relative 


sizes of individual parts of a whole. 


Figure 8 
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Graphics are also very valuable in Showing exceptions and varian- 
ces. This is an essential analysis for those Managers who manage 
by objective or manage by exception. Charts see frequent ap- 
plications in budgeting where forecasts are compared with actual 
results. The chart below shows how different departments within 
one division have performed on both a monthly and yearly basis. 
The bars depict what % of the forecast each department has 


achieved. At a glance, it is clear that departments two ana 


three have reached or exceeded their goals. Department one 


has had a poor month, meeting only 50% of its goal but is still 


almost on target for the year. Department four, on the other 


hand is considerably below expectations both for the month and 


the year to date. 


Figure 9 


SALES TO DATE 


scomnerct VIDFCT 
Wii LLL, 





Solution Formulation: After completing analyses, the decision 
maker may have enough understanding of the problem to generate 
several alternative solutions. If so, the decision maker can 
choose the alternative that best fits the decision criteria or, 
if the problem is not fully understood the decision maker can 


redefine the problem, collect more data, and do more analyses. 


In generating alternative solutions, a manager may choose to ma- 
nipulate data in several ways. To accomodate this activity, DSG/ 
3000 has built in transformation capabilities: cumulations to 
give totals up through a given time period; moving averages to 
smooth out irregularities in trends; logorithmic scaling to dis- 
play variables which have values very far apart, and several 
others. Manipulations of the data can be performed within DSG/ 
3000 by simply filling in one menu -- there is no need to exit or 
write specia] programs. Below is an example of some cumulated 


data: 


Figure 10 
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Communication: Once the best solution has been determined, the 
answer can be communicated to those who need to act upon it. 
Quite often this step is overlooked in the decision-making pro- 
cess and yet it is probably one of the most important. How often 
do senior managers redefine problems, ask for more data or 
request additional analyses? These activities- often set the 
whole process in motion again which explains the extremely itera- 
tive nature of the decision making process. This points out the 
necessity of being able to easily update and create graphs man- 


ually, as well as using them for periodic reporting. 


In fact, very few managers make decisions by themselves, most 
often they must seek approval from higher levels. This in part 
explains why managers spend 46% of their time in meetings and top 


level managers spend only 2 - 3% of their time dealing with 


computers. 


As we discussed earlier, business graphics are very valuable in 
meetings and presentations. They can reduce the amount of time 
Spent in meetings or make the time spent more productive by 
rapidly conveying the most relevant information in a concise and 
interesting format that will maintain the listeners interest as 
well as improving their retention of key points. DSG/3000 pro- 
vides presentation quality graphs and slides appropriate for re- 
ports and meetings. In fact all the graphs I have shown you to- 
day were created with DSG/3000. One major consumer package goods 
company in the United States found they were able to reduce the 


cost of producing presentation slides by 50% using DSG/3000. 


The ability to store the data and chart information separately 
allows users to update graphs on a periodic basis without 
recreating all of the chart specifications. Arrows, text, and 
lines as well as color selection can be employed to highlight the 
most important information. The ability to put multiple graphs 
on one page is also very valuable since it allows you to show 
relationships between various elements of your data. The two 
examples below demonstrate the amount of information content that 


can be placed in a graph. 


Figure 11 
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VI. CONCLUSION 
The trend toward office automation will continue at an accelerat- 


ing pace as word processing and data processing systems are inte- 


grated over the next decade. In addition to productivity im- 


provements for secretaries and clerical personnel, more sophisti- 
cated tools will be made available for managers and profes- 
sionals. Some of the technologies that will come into widespread 
use are electronic mail, teleconferencing, personal support tools 
for scheduling and calculating as well as sophisticated decision 


support tools. 


Graphics are already playing a major role in improving managerial 
productivity today because of their applicability in the decision 
making process. In the future, charts will become an integral 
part of business reporting because of their exceptional abiity to 
Communicate trends, relationships, comparisons and variances. 


Lets quickly review why this is true. 


Graphics is an especially useful tool to managers because of: 


Information needs <-- 
Graphics can provide concise summaries of the most 
relevant information in a visually appealing format that is 


easily understood by others. 


Daily Activities -- involved in making many interrelated decisions. Graphics 


can be a valuable resource in this iterative process. 
Graphics can assist managers in communicating to others in 


meetings (46% of their time) and in creating documents (13% 


of time). The ability to understand material when reading Thus, managers with graphics at their fingertips, despite their 
(8% of time) and do sophisticated analysis (8% of time) is differing management styles and job descriptions will have access 
vastly enhanced with the use of graphics. to more relevant data, in a more concise fashion, in an easy to 


comprehend format, that will let managers spend more time doing 
Decision Making Process 
what they do best -- making decisions. 
Graphics can help all steps of decision making by focusing 
attention on the most important facts during problem 
definition. Computer graphics with data base access ex- 


pedites the collection of data in a highly accurate manner. 


Graphics is probably most valuable in analysis because it 


quickly shows trends, relationships, comparisons, and 
variances and exceptions. Combined with some simple 


Statistical tools, graphics can be invaluable in exploring 
alternative solutions and visually displaying "what if" 
analyses. And last, but probably most important, it can 


communicate information to others. very effectively. 


How can Graphics Help Management? 
Planning, organizing and controlling-- These key in- 


gredients of management are each a series of interrelated 
decisions. Planning for example asks the questions who 
will do what, where, at what cost, etc.? Budgeting is an 


excellent example of planning in which many people may be 


VII. IMPLICATIONS FOR DATA PROCESSING MANAGERS 


Today senior managers are looking for better more timely informa- 
tion. They are looking to their management information systems 
personnel to improve their decision making capabilities. This 
means providing better information rather than just more data. 

It also means providing it in a more succinct, highly compreh- 
sible format like graphics that can be easily understood by busi- 


ness managers. 


In the-future, those managers and professionals who use graphics 
will be able to more effectively manage their businesses. And 
those computer systems specialists who implement graphics on 
their systems will be able to provide higher quality information, 


not just data to their end user decision makers. 


In fact, one observer pointed out that the role of DP directors 
in the future will change “from technician to management scien- 
tist. [3] But, it is up to you, the experts on computers and 
information systems, the professionals who are abreast of the 
latest technology to show managers throughout your organizations 
how they can be more productive using the tools and services you 
provide. They will not come to you because in most cases, they 
are successful now and they are not aware of many of the tools 
you have at your disposal. You need to be the agent of change 
and take the lead in improving your organizations management 


productivity. 
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This onvoer wiil discuss various techniaues utilized to increase 
the reliability of aoppiication software and to simoiafy the 
operations management of the HPS00H. Tonics presented will ianciude: 


~ MONITOR 
- Lomplete system security. application controi and frienaiy 
user interface in a single online oregram 
~ A GENERAL PURPOSE AUTOMATED CONTROL APPLICATION 
- How to insure that what one proaram writes to a fale if 
. the same as what the next orogram reads 
~ INTELLIGENT DATABASE CAPACITY CHECKE. 
- How to orevent databases from hitting capacity, theresy 
avoiding time-consuming recovery ang clean-uo 
- PRIVATE VOLUMES 
~ How Private Votumes are meant to be used to 
(4) better utilize dise Grives 
(2) insure data intearityv and security 
(3) do system backup 
- APPLICATION TESTING 
- A sound testing strateay that nays off in the lona run 
~ IMAGE LOGGING 
~ Showing its benefits both online and batch 
= ATSeeE tL oneov: 
Kev file recovery after catastroshic crashes 
- Buildina filés to avoid run-time aberts 
- iJniaue approaches to JEL. UDC’s ang MPE canability 
maintenance 
~ Utilizina "INFO=" for passing oarameters to COBRGL 
proarams 
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The Accounting Systems Grovo of CSY reports to the CSY “ontroiler 
and handies all accounting data vrocessing for CEY., Qur roie within 
the Accounting Department is to support and deveion computerized ac 


Ccountina systems. 


tn addition to support we have become heavily involved and geai- 


cated to; 


(4) Testing new HP products - both hardware and software. 
This includes not only doing pre-release testing for 
functionality and reliability but also utilizing these 


products to develop our distributed environment, 


(2) Fully utilizing HP software and hardware to implement a 
"distributed" data processing environment. i.e. one in 
which the comoutinag power is where the oeople and 
problems are. This includes addressing the nroblems ot 


system security and operatorless-comouters. 


We currently have our applications spread across two HP4S0C0 systems, a 
SERIES 44 ano a SERIES 33, with a total of about 1660 Mb of disc 
storage (‘four of our disc drives are Private Volumes). One &@64°AR Gaes 
the printing for both machines (we use BS/3900 to copy spoolriles fram 
the Series 33 to the Series 44). We have one HPi2S microcomauter in 
the department and “aie currently evaluating an HPSU0G to be put in 
Accounts Pavable for dedicated processing. Our systems grous of 12 


professionals supports an accounting department of 40 Geople. 
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A GENERAL PURPOSE AUTOMATED CONTROL APPLICATION 

Une of the tasks a systems adminiustrator has tO Go 368 to verity 
control totals for batcn jobs, Most of our batch J9OO5 Consist G6? muiti- 
Dle programs passing information through the use of Seauentuaal dase 
Tiles and for certain icbs it is not enough to successfulivy reach EOJ 
to say that orocessina was indeed Successful. we would have tne 
Oregrams within the t06 print out control reports to STDLIST ang the 
System administrator would manually verify tnat the control totais 


matched, 


We have designed and implemented an automnites control loaging pro- 
cedure that (1) is standard for all GgG1ication subsustems, (2) 
eliminates manuai calculations thereby eliminating human error, 3) 
Stores and reports the information being Joqaged, (4) directs thre RYE ~ 
tems administrator’s attention to variances in the jantrol tatals. and 


(5) is simple and straight forward to impienmuent, 


This - system, catied Controi fogs, 15 Gariven off a Gatanase that 
maintains the totals and the barameters tnat défine now the susten 
snould hangle the totals. Ali of the code to De inserted into each 


Drogram is kent in our convlib. 


The following example will show how Control tLoas works, Let 
Drogram "A" write out data to a Vile named "DD", nen groaram "8" wild 
use file 0D as an inout file tao ae further Drocessind. in gragran A. 
each time a record is written to D two totais are KENT Cin acceuntana 
We usuaily keep recorad count and a doilar totais and at tha ena of 


program A the control Loo subroutine is cated, Tha Takes the tetalis 


yi 


we 


puts them into the database, and then orints 4 Standardized contre 
report to STDLIST. Then program EB comes Glona ang as it reads File DB 
it keeps the same two totals that A kent. At the end of its mrocessind- 
it also calls the control logs subroutine but it will compare its to- 
tals to those in the database for file D. Jf they do not match an erroer 
report is orinted showing the differences and the subroutine anorts the 


program, 


There are several functions tnat can be accomolisned witn Controi 


Loas: 


(1) Replace —- this is used by the program creating a file as 
was program A in the example above, The totais taken are 


Dut into the database ang no further processing is done 


(2) Compare - this takes the totais being passed nu the 
program and compares them to the totals presentiv in the 
database for that particular file. FF they do not match 


the program is aborted and an error message 15 orintea 


(3) Update ~ this takes the totals bein passed by the Dprour any 
and adds them to the totals already in the catabase ana 


the resulting new totais are then gut in the database. 


(4) Compare and Update - this does the compare function first 
with the first two totais passed and then doet an Unagare 
using two optional totals that are used for this function 


and function ¢5) 


ge. 


(S) Compare and Repniace - this does the Campare function INTELLIGENT DATARASE/FILE CAPACITY CHECKS 
first with the first two totals oassed and then does an 
Recovering a datanase after a datase* has hit camacity an ome al 
Update using the second two totale. 


the more painful recovery processes. Using [MAGE LCGGING neins necauas 

We now currently have all of our batch processing using Contral vou can recover right vp to the process tnat filled the acataraze ou 

logs for every. file that is passed between two or More programs. you still have to retrieve the database from your last backun and run 
Generaliy, it has not been inconsistent data that fas led to Control the log file back in. It is also difficuit to alwave keen ragait on ten 
Logs mismatches, rather it has been that when we fir bugs in programs of the anount af? hed Weace. Suen datasen iwiahin ween wesasase Hae: 
we have inadvertantly introduced other bugs that affect these files. Tnat 304 or so free soace vou like to maintain can Gistapneéar alaresangis 


quickly and when it does vou are fnacea with what we reter te as a 


“capacity abort", 


; Alona with databases, data files can 2 used iN A SimM_Lar Manner 
Where free space is maintained and informotion is “Gosenteo’ te tiie 


file on a reaquiar basis using "ACC=APPEND" on file enunatians. 


What we nave developed 15 a Simple method of “in -fraont" capnecatre 


Checking within orograms so that processing can pe termingtaa marers 


any data i5 out to the database aor file in the caste where 


not be enough space available. 


We do almost all of our Drogramming in COB. ana with OSGi 72 
MPE INTRINSICS can be calied girectly so that none af roe We Are Gee 
to do reguires anv fancy subproutines or fOQLNG. Me waar Ce tee 
MODE202 calls for datasets and “FGETIRFO" anteansac cable Csr fuk 
gail current-count and canoacity informatiar can be cotaeineaga., fro" thare 


it tS only a matter of Géetermining if what vou nave ta mur an eara Tart, 


The following example will nein: . 
fhe anove example is a simole out vearv ogwartul case af Row t4 
ORK KKK KKK RK KAR KKK KH 


/ \ avoid database receverv. AS mentigned before. the Some checksne can Be 
: TRANS DATA FILE : 
\ c done tor ACCESG=APPEND tyne files. Also «a datoset or File can ma teat- 
KKK KKK KKK KKK KKK KK KKK : 
; . ed fer 4 percentage of fulai canacaty., 2 gage SSR ge “tao Ful then 
a 
‘ 
aes the orogram can 08 aborted when @5% or grenter t8 reached. ~"4e inmgar- 
ORO OK OOK KKK AOR ROKK KKK 
x ¥. Tant Goint a8 that the cneck BE put in Gt the begarning mePore saw ese 
x VALIDATION * | 
x PROGRAM %. of processing has b8aGunN $6 That tne oragram can sagihy mea restar tes 
K * 
KAKO OK KKK RAK OKA KOK KK from the begaicning, 
H 
: 


\- 7 
MOR KKK KKK KKK RR KK KKK 
* * 
x VALID-REC~DTL* 
* DATASET x 
x x 
KKK KK KKK K 


Figure $3.0 Database Canpacity-check example 


We have a oroaram that on a daily basis reaas in a transaction 
file called "TRANS". Each record in TRANS is valicated ane our to a 
dataset called "VALID-REC-DTL”" in the HOLDOB Gatabase. The VERY FIRST 
CODE within the PROCEDURE DIVISTON does tnree things. 


(4) Calls the intrinsic FGETINFO to find ovt hos many records 
are in the TRANS disc file, 


(2) Calls DEINFO MODE202 to get the current record count ana 
the capacity of the VALID-REC-DTL of HOLDVE., 


(3) Adds together the number of records in TRANS and tne rum 
ber of records currentiyv un VALID-SEC-DTL and if than ta 
tal ais GREATER THAN the cnoacity of the dataset the 
oroaram aborts itself (after oraunting a mezsage explacn- 
ing the situation). Abortina the worogram adsorts a datcn 
process thereby effectively Stopsing mrecessing eo tre 
database can be expanded. 


PRIVATE VOLUMES 


eeee coer sete vere Oeee SOEE SED OOH CBSE Fabs EOED HHO oFEE Seen cane 


In moving towards an ooperatorless environment Private Voiimes have 


piaved a key rote in several ways. 


We now use private volumes for almost all of thea processing that 


used to go to tape. An HP7925 disc pack can hold about 32 1é00bo1 tapes 


worth of information. Using theMPE command "VACUNT GN.ASTO" watn a 


private no one has to to "REPLY" wnen the nack if needed. Ali tne aa 
vantages of disc access are available as Welt as the “nse of 


removability and storage that tanes have. 


We now use orivate volumes for all of our martial dumos Cayatam 
backuo),. We use the volumes as "SERIAL DISCS" and 35 we backun to dase 


the same wav we used to backup to tabde. 


We have found that using private volumes for backuD if Poster oe- 


mause of the lack of multiple tane mounts and that Ggise packs do not 
suffer from the parity errors that are frequent on aging tape. on Gav 
found tnat that call fas 


to-day use we have MAior system crasnes 


reloads seldom destroy the files on ovr private volumes soa that oni 


system-domain drives need to be relonded. This has cut nur réeioas tire 


to less than half what it was before. 


We have created a orivate volume called "SPACE" that has one groun 


on it also calied SPACE. This pack is mounted whenever we need to cho 
extremely large sorts. What we do is to "noint” our sort files ta SPACE 
and do all of the sorting on this completely emoty HE?925 pack (thates 


nearly $00,000 sectors of sorting svace!). 
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APPLICATION TESTING 
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feina a systems group that does application maintenance ab weil as 
development we do alot of testing on existing Systane 25 buge are fPaived 
and orograms are enhanced. In the past we aiways tested with a subraet 


of our 


“Live” data in a group mace just for testing ana there were 


rules or even guidelines on testing. What hasoened wos that: 


C4) 


2) 


Test data wos easily Gestroved as ome Dereon wouvid wurde 


files or aiter data that another nad set uo. This usualiv 
dicn’t happen 
done out when he came back a manth later ta use the anata 
moregram he Pound Nag mraar 


to test a new cnange in the 


data (which fe knew and understood) gone oF aitered. "514 
created a SituGction where test Cats untegrity was nines 


istent and much time anda effort ware wasted Giways mayving 


To mwecreate data. 


Hecause the test data wasn’t oactyaliv designed it vary 
seldom really "tested" the programs it floweG toroeugn. Te 
be meaninaful each different tyne of transaction must be 
incivuded in the data and especialiv omnes that fuliv exer: 
has been changed. 


cise the area of the oroaram that 


Production data also generally contains a nigh volume at 
oniv a few tynes of fhe Kpanseetaons $0 that when date 
is ijivust beina conied from the live gata fiies it usuaiiu 
wasn’t of much worth except to see if the program coula 


run from beginning to end without asorting! 


while woth were tezting., The Pareto wan 


(3) Because the test data wasn’t actually défigned st war 
very seldom that the programmer REALLY understooag the inn 
terrelationships within the data and the program, Vere 
often the programmer was simply putting in cade that he 
was told te put in and wasn’t ever unGerstanging tHe 


problem to be solved. 


This list covld ago on and on. Gur solution to tne pronlen 1s woat 


we call "“TESTBASE". 


TESTBASE is a groups within our FINANCE account trat iS Gesianed toe 


be ‘a compiete, self-supporting envirenment far the testing of sur 
Accounting software. Evy "comolete” it iS meant that using the 
procedures we've outlined, TESTBASE can be enhanced to fubde test any 


"Live" scenario desired. By "self-sunportinag” it 13 meant that ciosure 


exists within TESTBASE’S set of data, 


Listed dSelow is the set of auidelines that we nave get uo far 
TESTRASE. The way TESTRASE works in practice if that we keer the groun 
TESTBASE as a "clean” cany and for each person we have a aroun for then 
to do their testing in. When we create this grovo WE Gave tren a cope 
of all the necessary files that they wiiil need from TESTRBASE Aaece 
make sure that when testing is finished that they ao back and acd t5 
TESTBASE the new test data that they have Geveloped. We have found that 
for TESTBASE to work requires a serious commitment and effort from 
mandgement but that the testing time saved, the increased tnoravahness 


mt 


ff 


and quality of testing, and the knowledge gained by the orosramm 


makes TESTBASE one of the best investments we’ve monde. 


i3 


TESTBASE 


(1) 


C4) 


(5) 


guidelines: 


TESTBASE should have complete closure. Any data néeeced 
for j0bs, validation, etc, will be kept witnan TESTA... 
If needed. TESTBASE could be removed to another machine 
Along with necessary program files and Gil testing could 
be accomnlisned. 


Naming conventions shouvld be ingéependent from actual 
naming conventions. Most oroguction nanmsng conventions 
eq. Part-Numbers) are not tne result of oredefines 
naming schemes designed to minimize start un coste ana 
overhead involved in user understanding, TESTBASE nanes 
wili try to be as simple and orderly a5 is mnossible., 


All test data should be indenendent of actual production 
data vaives. In this wav aata can be designed to orayvide 
specitic information to the testor. 


TESTBASE shovid be recoverable. This Means thet at ame 
time the orogrammer may retreat Sack to time © and Hagin 
gqgaqin with exactly the same scenario or environment ne 
started with. Aliso, with not bteina tied to the proguc~ 
tion environment testbase or any part of ait means 
TESTBASE can be stored at anv point in time during test 
ing and then at anv time be recavered ts that wboint for 
restart. 


TESTBASE should be Gynamic in that whenever it i3 us 
time should be taken to enhance the original testvane 
that (a) it does not become outdated ana (Hh) 85H that 
testbase grows with new databases anda files being ade 
to increase the range of systems that can be tested 15 
the future without having to “reinvent tne wheel" wath 
eacn new user, 


IMAGE LOGGING 


santo CGD ene 00S Ente SEED eEED OED EADS COND caED caT cost 


In our environment we are using Image Logging Gar virtuaiiv ii oF 
ovr databases. All of our loading is Gone to Gis anG we've Piaiizred 


some unexpected benefats from having the logging orocesses. 


First, we’ve seen no problems witn lagging to aise, When we Susan 


our loa files we obtain the disc address of the files Ga TAST in « 


tes vi 
: 


serious crash we can ovll the files off to tane vesing SADUTIL (see 


MISCELLANECUS section on Key file recovery). 


Second. one of the biggest denefits from iegagsng comes not from 
when the system crashes but when an application aborts and we need to 
recover the databases involved. It is nuicé being oie te recever a 


of An aboiicat.on and 


st] 


gqatabase riant uo to the beginning of orocessin 


not iose Drevious orecessing to that datasase, 


Third, -the incremental orocessing time involves witn lagging is 


unnoticeabie and implementation of logging requires no broaram changes. 


is 


A common oractice we've seen ifs to out OBSTORE’S at the beginning of 


A558 m7 Sai time! 


~~, 
La 


c 


iT) 
--y 
_ 
oy a | 


366 streams for recoverability. That Gefanmiteiv a 
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MISCELLANEOUS TOPICS 
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Key file recovery after catastroohic crashes 


imum OMe CObe CECE ates EEOt GRD aEnT CUED SEED GrEL ene: come epee cane Gane Sot GIES EDED NIMS Onbe SERS coTe Bees Cree ans GARD OOS OEEL Sime OHS SEER SEES Ont! OEE: 807% Ente EEDS GME SEBS SOM een Otte oot 


There used to be a time when catastroohic sostem crashes meant a 
total reload of the system from the iast backup. For Accounting thas 


meant losing all the processing that had occurred from backun to the 


crash. However, with aoclittle planning and a Svuetem utility callec 


SADUTIL ‘see MPE Systems Utilities reference manual - Part Ne, 
30000-90044) files on the inonerabdie System can be copied to tase and 


thereby recovered, 


Planning needs to be done because if the suvstem directory is 
destroved in the crash, the only way to get the fale is te know the 
logical device it resides on and its starting disc asdress. This infor- 


mation can be obtained from the MPE STORE command using the SHOW oagrai~ 


eter or can be obtained by doing a LISTF within LISTDIkF2, PUB. SYS. 


In our environment we use both, Gerending on tne specific file. 
For our Image Loaging files we put LISTDIR2 in the job straam that 
builds the log files. This wav the address 285 arunted right on the 
STDLIST and filed with the backuon iistinas. For the few strategic files 
that we need to keep track of their whereabouts on the system, we’ ve 
out LISTDIR2 into the iob streams that create the files. If the system 
crashes, we get the address of the file from the last STDLIST for thar 


job and use SADUTIL to get our file back! 


i 


Building files to avoid run-time aborts 

When building files within job streams the "DISC=" Paraneter of 
the BUILD command can be used to allocate the entire amount of Gisc 
space needed. This i5 accomplished by setting the anitial aliscation 
‘eaual to the number of extents (remenmoer that 
DISC=[numrecil.{(numextentsl{,initallocd)]) > so tnar DISS=20000, 22.40 
would allocate the entire space for 10.0906 records or fail due to iack 


of disc space. This way lack of dise space will atart the jo0 Stream 


outside of, and before the program that would’ve usea tne file. 


How not to lose JCL 
In the oast we had alot of problems with ‘the STDLIST that i3 
printed for every batch job. First, ait seems as thaugh STDLIST’s nage 


eject the line printer about every other Line. This alwavs destroved 
any attempt to keep paper piling properly and jammed the printer on a 
regular basis. Secondly, user’s don’t understand tne importance of 
STDLIST’s so they aot thrown out, filed with reports, inacvertantiv 
left attached to somedbody’s outout (and therefore thrown out). .ate. It 
always seemed to be the case that the STSLIST was massing for tnat 


critical iob that aborted and trying to fix the job necame a aifficuit 


task, 


We have implemented a simple solution that has solved our STDLIST 
problems. Any job that has a STDLIST wortn saving nas had 
"QUTCLASS=LP.S" added to its job card. This defers the STDLIST so it 


doesn’t orint (Cour OUTFENCE is mormaliy 7) until a systems parson 
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prints it off. We print off the STDLIST’s once a Gav and file tne tnen 
Oy the day we print them off (this avoids having to Separate them), Now 
our printer jams alot less often and we always know exactly where the 


STDLIST’s are! 
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MPE IV?S “INFG=" PARAMETER 

MPE IV has a new parameter. called “INFG". for the RUN command. 
Using INFO alphanumeric information can be passkea to apoiiacation 
pDroarams., tefore INFG the only run-time carameter for passing taAforma~ 
tion was "PARM". and it nandled oniv numeric informaticn., 

We have written an SPL subroutine that retrieves the alonanumeric 
string and the lenath of this strang to a COBOL II oroagram., A simole 


LGOBOw examole and the subroutine listinga follow: 


WORKING-STORAGE SECTION. 


PTC ACSO). 
PIC S9(04) 


Hi INFO 
014 INFO-LENGTH Com, 


CALL "GETINFO" USING INFO. INFO-LENGTH., 
From MPE:; 


2RUN PROGRAM: INFO="HELLO-THERE 


i? 


PAGE 000i 


00000 
00000 
90000 
00000 
00000 
00000 
00000 
00000 
00000 
00006 
00000 
00000 
00000 


00000 


00000 
O00GG 
00000 


00009 


00000 


00000 


00000 
00000 
00000 


090006 
00003 


00005 — 


60005 
00005 
00005 
00007 
00012 
00012 
00012 
G0045 
00045 
000415 
00020 
00022 
g0022 


00023 


0 
0 
0 
0 
0 
0 
0 
0 
0 
0 
a 
4 
4 
4 
i 
1 
2 


a] 


fa 


fo 


Po 


fu NM Pots M fo fof Pfu fe fo fu fo fo 2) 


fh to fo 


fe 


HEWLETT-PACKARD 32100A.08,.04 SPLI4w3 


% 
$5 i} N : 


SCONTROL SUBPROGRAM,.MAP .ADR ,SEGMENT=GETINE SG 


S$TITLE 


<< 
€¢< 
¢< 
<¢ 
{< 


"FMS06155S = GETINFO" 

THIS PROGRAM WILL RETURN AN G9 CHARACTER & 
AND THE LENGTH OF THIS STRING 

TO A COBOL PROGRAM THAT WAS RUN WITH THE " 
OPTION. THE ADDRESS OF THE STRING IS STGR 
G-S AND THE LENGTH IS STORED IW Q-6 AT UR 


BEGIN 


PR 


OCEDURE GETINFOCINFO.LEN) : 


ARRAY INFO: 
INTEGER LEN: 


BEGIN 


LOGICAL QSTART=@: 

Q +000 
INTEGER, DELTA,.X: 

Q +004 

Q +002 
BYTE POINTER PINFO: 

Q +003 
POINTER P’LEN,PO.PREG: 

Q +004 

Q +005 

Q +066 
POINTER W’PINFO: 

Q +607 
LOGICAL VAR: 

QO +6496 


SET POTHTER PG TT CUR 
VALUE OF G-REGISTER 


ou es 
on™ 


SET POINTER TO VALUE 
P-REGISTER IN STACK 


Q-- 

on 

j 

tt! 

~~ 

oe 
‘, om ~~ 
™ ow 


£¢ SET POINTER TO WHE 


€¢ RUN INFO ADDRESS WILe MED? 


RETURM LENGTH GF >; 


@P7LEN := @PG - 6:3 << 
CCSTRING FROM O(19-G6>> 


<{ END Gr STACK CHAT, 
. << CAN STOP NOW 
THEN .GOTO STOP? THIS: 


met 
iP 20, 


TRING 


INF G=" 


Ev Ih 
TIME. 


FENT 


OF 
MARKER 


RE 


>> 
>? 


FIND OUT HOW MUCH TO CHANGE G 


wf 
4?é 
2? 


Nw oN 
4, 


t 


PAGE 


00025 
00025 
00027 


00032 
00032 
00053 
000355 
600335 
00033 
00033 


80035 
00037 
00041 
06044 
00100 


00104 
C0104 


06000 


PRIMARY DB STGRAGE=Z4000; 
NO. ERRORS=0000: 


PROCESSOR TIME=0:00: 01; 


0002 HEWLETT-PACKARD FMS0615S 
2 

2 X := @PQO: 

2 @PQ := X - DELTA: 

2 

2 GOTO AGAIN; 

2 

2 | 

2 STOP*THIS: 

2 

2 @WPINFO := @PINFO;: 

2 VAR := W*PINFO: 

2 @W’PINFO := VAR: 

2 @W’PINFO := @W’PINFO / 2: 
2 MOVE INFO:=" 

2 MOVE INFO := W’PINFO, (LEN): 
2 

2 END: 

IDENTIFIER CLASS 

AGAIN LABEL 
DELTA SIMP. VAR. 
INFO ARRAY (RD 
LEN SIMP. VAR.C(R) 
P?LEN POINTER 
PINFO POINTER 
PQ POINTER 
PREG POINTER 
OSTART SIMP. VAR. 
STOP? THIS LABEL 

VAR SIMP. VAR. 
W?PINFO POINTER 

x SIMP. VAR. 

4 END, 

IDENTIFIER CLASS 

GETINFO PROCEDURE 


GE TINE l 


<< SET 


€4 


POINTE? 


<< DECKEMENT G-PTR >> 
€¢ TO PREVIOUS 
CC VALUE AND START AGALN: . 


>? 


TALE IF Gs > 


eu 
i? 


UP 


CCRETURN INFO >> 


« ¢ 


TYPE 


INTEGER 
LOGICAL 
INTEGER 
LOGE CAL 
BYTE 

LOGICAL 
LOGICAL 
LOGICAL 


LOGICAL 
LOGICAL 
INTEGER 


STRING 


ADDRESS 


PR ius, 
is +6002 
a -OO°, 
i -)g4 
QO +804 
9 +093 
wv +00 
& 4906 
) +000 
PERE G3 
Q tad 
3s +007 
w@ +008 


ADDRESS 


SECONDARY DE STORAGE=%00005 
NO. WARNINGS=C 9000 
ELAPSED TIME=0:60:07 


